> Not In Your Best Interests
I say what's in my best interest and py3 fixed a lot of issues for me. I'm happy with the upgrade and dropped py2 for new projects this year.
> No Working Translator
A flawless translator is simply not possible. 2to3 is the best effort idea. At some point you'll run into `def f(x): return x` and without doing a full program static analysis you won't be able to say what's the right translation. You have to do it manually where needed.
> Difficult To Use Strings
I understand that the py2's "just works" strings are easier. But at the same time, having a non-ascii name I know that most applications "just work" simply because nobody actually tested them outside of ascii set. Py3 doesn't explode on encoding for fun - it basically says: you made an assumption that kind of worked so far by accident, but now you need to say explicitly what you want to do. I think it's a good thing, even if it takes people time to adjust.
> Core Libraries Not Updated
I don't even know what he means. This really needs an example, or it's just a meaningless rant.
> Purposefully Crippled 2to3 Translator
As above. Some things are just not possible to translate without knowing what the programmer meant. Some things in py2 strings happened to work a bit "by accident" and simply won't work in py3 for good reasons. For example py2 code:
In : "abc".encode('ascii').encode('ascii')
The string/byte confusion is an issue for people who like to pretend that they're the same. They're not. A string can be represented by different byte streams depending on the encoding. That by itself tells you that they are not the same and should not be treated as the same thing. But we have many decades of conflating the two, and old habits die hard.
> You Should Be Able to Run 2 and 3
That makes no sense. The whole point of versions is that they are different. Maybe he means 3 should be backwards compatible. That is potentially valid criticism. That said, AFAICT, the breaking changes are pretty reasonable . Also, I'm not sure what world he is living in, but interop between Java and C/C++ through the JNI is not easy. As a math major I'm not sure what the "solid math" here is. I think it is ironic that the CLR is referenced here so extensively - it has made some pretty big breaking changes in the past (unlike Java, it decided to break backwards compatibility to have reified generics).
Translation is tough, _especially_ in languages like Python that don't have good static guarantees. The real problem here is probably that the code you want to produce with a translator should look as much like the original code when possible. That _is_ tough. The point is it isn't just what the program does in terms of inputs and outputs that you want to preserve. You still want it to look more or less the same.
This is not an incorrect point. I think Python 3 wanted to have both the performance of byte strings and utf8-by-default strings (finally!). The intention behind that seems reasonable. As a proponent of strong static typing, the error message he shows seems quite benign. That said, I understand how one might be unhappy about this.
This may be the case, I'll defer to someone else. That said, this is yet another claim the author makes without much backing (this alone could be the subject of a blog post given the right backing). The quip about the Python community liking bad design seems a bit gratuitous.