>Just rip the band-aid off. Some of the async stuff in Python 3 is awesome.
Will that awesome async stuff help us migrate several 100s of thousands of lines of 2.7 code?
Will that awesome async stuff help us migrate several 100s of thousands of lines of 2.7 code?
Yeah, right. There's a reason even companies with tons of resources like Google still use 2.7.
But good news, you don't have to do it. Python 2.7 will still work after 2020. We, the community, will just stop working on it for free. You can start paying us, or do the job for free like we did since 1991.
You can also migrate to another tech, but they will break things as well, and they won't give you 12 years to move. Ruby and node gave 2 years. Node forked 2 times. And it's a google based tech.
I'm tired of hearing complains, given how good you have it.
However, I understand that those benefits might not be motivation enough to migrate in some contexts.
In those cases, I advise to freeze the project in time, isolating it by vendoring dependancies and either compile it with nuitka or distribute it in docker.
It took Flask several years, complaints, and a custom change for their use case, to port over.
Some people have actual production code which they don't rewrite for the fun of it (and even less with comically underestimated "2 weeks per 100K" runs), because the core decided a non-backwards compatible version is the future.
>But good news, you don't have to do it. Python 2.7 will still work after 2020. We, the community, will just stop working on it for free. You can start paying us, or do the job for free like we did since 1991.
Well, you're not the "community", at best you're one committer. The community (not necessarily the core devs) will fork and maintain way beyond 2020, and it will be for free too.
>I'm tired of hearing complains, given how good you have it.
Sorry, didn't know people must walk on tiptoes lest they tire you with their complains...
I think the overly backward-compatible way in which the change was managed really prolonged the adtoption and getting python 3.x to mature. The Python-Community was hanging between those versions far too long and it really hurt the ecosystem and the whole python-experience.
> Some people have actual production code which they don't rewrite for the fun of it (and even less with comically underestimated "2 weeks per 100K" runs), because the core decided a non-backwards compatible version is the future.
Of course, but you (probably) still have to maintain the code. And it's not a full rewrite, more an adaption. I find most changes to be quite mechanical. Also, it's not the python-comunities fault, you chose python and you're getting probably using it for some business purpose. So i think the python community can expect you to maintain it, including language adaptions. You can still ignore this and don't update, but libraries will probably start getting incompatible and there will come a time when things break. Wheter that's important enought to migrat is up to you.
I don't think it's fair to just complain loudly, after all, the python community is not expection a full rewrite. They have given enough time to migrate, i think took much, but it's still a lot. Being completely backward compatible forever was never promised, and i think is an complete anti-feature. Write once and never think about it is not the python-way, but having a clean, smart, elegant language. It also really hurts java, which just walks with all the backage of the past and glacial speed for language-updates, which probably is required when everything you do is going to be kept forever in the language.
I would go so far as to say that Python 3.4 was the first one you could really use in production, that leaves you with 5 years to handle the upgrade. Still before that you should at least have started to add basic stuff like importing print_function and at testing all new stuff against Python 3. Many just kept ignoring Python 3 and wrote line after line of new incompatible Python 2 code.
I no longer feel sorry of those who are stuck on Python 2.7 and now have less than a year to upgrade. At this point it's your own fault.
You'd need insane test coverage, of all possible code paths, to be 100% confident.
Most of the conversion difficulties were related to Unicode/text/binary string handling in Python 3, and 2to3 didn't catch all of them. This was the biggest challenge of the entire process. Stuff would fail in production because due to improper string handling. Python 2 was remarkably permissive (i.e. loosy goosey), whereas Python 3 is stricter and arguably more correct, but this strictness has a cost.
The other class of problems is the restructure of certain std libs, like urllib. We took the opportunity to move away from "urllib" to "requests".
This site [1] was invaluable in understanding the migration issues.
All in all, apart from breaking Unicode issues, the migration process was fairly easy.
In the end I decided moving to Rust was less work than Python 3 (in terms of being sure my program was reliable and wouldn't error out with unicode errors).
That means the code was working with raw bytes, not utf-8 strings, so that's what you should convert to on Python3.
That means using `.encode()` and `.decode()` or using bytestrings.
Python3 doesn't break string usage, it makes you do it correctly. Expect a lot more of that kind of pain by moving to Rust (not saying it's not worth, you'll indeed get more correct programs done).
I found it much easier in Rust, as the two types are just distinct, and an incorrect program just fails to compile.