Comment by jefb | Hacker News Reader

Comment by jefb | Hacker News Reader

Parent Full thread

Number one reason why I haven't switched yet?... print. Admittedly is is the dumbest possible reason, it's irrational; I would never admit it in a face-to-face conversation; I would deflect to "something something third-party library...", but deep-down inside, if I'm really honest with myself, it's print. I want asyncio, I want better unicode support, but all I think about are SyntaxError's in what I __strongly__ consider to be valid python.

My stubbornness is rooted in the simplicity of print. It is so simple and stupid, why change it? Never has a production app relied heavily on print, it's just a dumb way to check shit while developing. I mean sweet jesus if it ain't broke right? I know I'm wrong in thinking this kind of thing happened everywhere in the 2->3 increment, but as I said earlier, I'm under no illusion of rationality. Python 3 broke hello world, and that just skeeves me out.

Eventually I'll write new stuff in 3, probably sooner rather than later especially with asyncio et all, but for now I'll stick with 2.

   Python 3 broke hello world

   Python 3 broke hello world

   Python 3 broke hello world

   ...

Yes, yes, yes, a million times yes. The print change really grates.

People say "print became a function", but that doesn't do it justice. Your quip is infinitely better.

If you are saying print is gone, it isn't. It became a function in python 3.

   print "hello world"

became

   print("hello world")

If you are complaining about the format, then that really is a dumb reason.

I'm also embarrassed about it, but I also strongly dislike the change to print. With this combined with a lot of little things like the removal of __cmp__ (apparently without even a relevant mixin in the standard library!), removal of the cmp argument to sort, removal of encode('hex') and encode('base64'), and doing Unicode wrong[1], Python 3 really feels like a pointless quality of life decline. For this reason I still stick with Python 2 for my general scripting needs.

[1] http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

But cmp is so backwards and non-intuitive. Key is a vastly better api, and more performant too, because you can generate keys once and then do comparisons using native types.

Again, with the encoding the api is different, but it's still really simple.

These feel like walls for walls sake.

Key... well, I should elaborate on that. I don't usually use cmp in my own code, and while I can think of situations where I might want to, using a wrapper class implementing comparison methods would be easy enough (modulo the missing mixin issue!). It's semantically a lot more complex to create a new object for comparison than to specify a comparison function when the English description is "sort by X" (of course, when X is just a property, key=lambda a: a.x is enough), but since this is a rare situation, I wouldn't mind. However, I ran into that issue when trying to teach my brother programming, and for learners, semantic overhead is really hard to deal with. Now, Python has no responsibility to optimize for learners over actual programmers (indeed, I'd argue it's always been worse as a first language than people think), but this was a case of removing a feature that had minimal additional API surface or implementation complexity; it really felt like removing things for the sake of removing things.

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').

I find with cmp there's too much to remember - if a < b do I need to return -1 or 1? With Key it becomes really simple, and powerful:

    sorted(records, key=lambda r: (r.city, r.age, r.name))

For me there's a lot less mental overhead with the Key form.

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.

Ha, I feel exactly the same about print. The extra brackets feel odd.

Reply on news.ycombinator.com