The right way is to make sure that stuff that used to work in the previous version still works in the current version. Breaking people's work, especially work that spans multiple years, projects, knowledge, etc and expecting them to be happy about it is naive. Being condescending when they turn out to not be happy and try to avoid the unnecessary busywork forced on them does not help either.
This isn't just about Python, many libraries and languages (and some OSes - see iOS, macOS and to a slightly less extent Android) are terrible about this. The proliferation of semver with its normalization of breaking stuff (the fact that a dependency - be it a library or language or whatever - uses semver communicates that they have already decided that they will break backwards compatibility at some point) shows that most people are fine with breaking others' code.
If you make a mistake when making a tool, you can either leave it forever, permanently causing pain for users forever, or you can try to find a path to fix it.
That being said, a Python 3.0 which was _just_ “can’t call encode in string, decode on bytes” then subsequent releases fixing up other stuff over time would have been much nicer.
Like the “everything is iterators now” release could have happened later.
But that too brings considerable downsides.
For all its merits, C++ is an extremely bloated language, getting even more complex every release, due in no small part to its commitment to backward compatibility.
There's no perfect answer. Python3's decision wasn't stupid, they just chose one downside over another.
But as soon as you cross the mental threshold of making a breaking change (which expanding the IPv4 address space obviously was) then it's easier to convince yourself to make a bunch more breaking changes. And this is where Python3 really lost its way (IMHO).
One of the silliest design decisions in Python3 was (initially) removing the string prefixes like s and u. Now obviously Python2 defaulted to ASCII and Python3 defaulted to Unicode but this decision just made making libraries compatible with both, so much so that they added it back (around 3.2-3.3 IIRC).
There are also always decisions you make that in hindsight you wish you'd done differently (eg the mutable Date class in Java) but just because you're making breaking changes doesn't mean you should "fix" all of those. You still have to look at each one and ask yourself "does this really matter enough to justify changing it now?". The default answer is "no" and the bar for "yes" should be really high.
I feel like Python3 failed here too.
And look where we are. Python3 out in 2008 and we're still writing migration guides in 2019.
See perl5 to perl6 GWbasic to Qbasic to VB to VB.net
you either make a clean break or keep all the warts, Either way folks are going to be unhappy.
Keep the warts, COBOL, Fortran, C, C++, PHP, Excel
wait wuh? i thought these were just two of the dozen variants of the BASIC dialect... interesting!
Edit: If you down vote me please say why I should care about IPv6
There's also the issue that honestly, I have no idea what is using IPv6 and what's using IPv4 right now. On my internal network I only ever deal with IPv4, but I have no intuition as to what is using IPv6; I couldn't tell you off the top of my head if my ISP supports it.
One could argue that this is actually a significant benefit of IPv6, in practice.
It is so easy for people to just repeat what they heard even if that idea originated a decade ago and was valid a decade ago.
And that way we got into a mess of not migrating until pass the time it is no longer supported...
Also, using tox on the project to run tests against both python 2.7 and multiple versions of 3 and the work goes pretty quickly.
The time may have passed, but lots of code is still out there that needs to be updated.
Re: packages, one of the huge advantages of the C ecosystem has been that compiled packages are usually fine across language transitions, not only between major compiler version numbers but even from C to C++ which are much more different languages than Python2 to 3. How different would the Python transition have been if it were possible to load Python2 packages in a Python3 program?
not to pick on sentry here, but you know, my experience is that people are having a hard time migrating due to them using obscure tricks and features of python 2.7. so their code is breaking because the language evolved.
the saying goes write dumb code or something because debugging is twice as hard. if there is anything to learn from all this, it's to write dumb code because maintenance is twice as hard too.
that's all that is happening really!
From enterprise to a self run startup you have to see if it’s worth it .
Maybe that would be useful for a conversation with one's boss.
I think that's a red herring. Convincing your boss is an issue even for minor upgrades. In a previous job, we couldn't convince him to move from Python 2.5 to 2.7.
brew install vim -- --with-override-system-vi --with-python3
Look under Scripting Language Runtimes
https://developer.apple.com/documentation/macos_release_note...
- First cut a new major version
- Write a few tests if needed, they go a long way here.
- Update to 2.7 best practices and logging
- Run tests, commit
- Add a few future statements, commit
- Run pyflakes3 on it, fix, commit
- Run under 3.x/fix until clean, commit
However, if your project is huge and/or does a lot of string and bit twiddling it's excruciating. Hence the controversy between factions.