print "hello world" print("hello world")
[1] http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
Again, with the encoding the api is different, but it's still really simple.
These feel like walls for walls sake.
For encoding it's mainly annoying because now I have to manually add an import, which is more typing than before. To be fair, there is a cogent argument that my issues with both print and this mean what I really want is a different language altogether: one that, respectively, allows omitting parentheses for all function calls, and has some kind of implicit import. But other languages have their own problems, and this still feels like a paper cut.
Oh, and the annoyance is exacerbated by the interfaces of binascii.hexlify and base64.b64encode being broken. They both return bytes objects, which is dumb since the whole point of hex and base64 encoding is to represent binary data as text, and the most common thing to do with encoded strings is to insert them in the middle of other text. 'foo %s' % hexlify(b'bar') => "foo b'626172'"; to get the "foo 626172" I want, I have to do even more typing and append .decode('ascii').
sorted(records, key=lambda r: (r.city, r.age, r.name))
Encoding-wise, hex and base64 are not something I do too often, so their new interfaces don't worry me too much. In the cases you've mentioned you could create a simple wrapper function to deal with it for you.
I guess there's some reason for using bytes instead of strings as the output to the interface, but, as you say, it's definitely non-obvious.
There are lots of things that are a little different in python 3; I would say overwhelmingly for the better, on the whole. There just doesn't seem to be much point fighting against those minor changes when they're easy enough to adapt to.