231–240 of 513 posts
Are there some valid reasons that made 2->3 migration insanely hard for some projects? I remember seeing blog articles whining about print vs print(), but surely there are some more important stuff.
Earlier quoted context omitted.
IMO you're oversimplifying things without appreciating the scope of what went into Python 3. Core developer Brett Cannon's talk "Python 3.3: Trust Me, It's Better than 2.7" goes over most of the differences at the time (2013): https://www.youtube.com/watch?v=f_6vDi7ywuA
> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then…
As mentioned by several people already, the migration process from 2 to 3 was really painful. It will be easier for the Python core maintainers, but introducing a breaking change with the intent that that version 2 will be deprecated has probably caused more distress overall, especially maintainers of other open source projects which rely on a specific python version. Let's never have the same kind of breaking change…
I see people saying that the migration was painful, but my own experience with two separate Python 2->3 migrations were so smooth they might as well have been a minor version bumps. I don't know where this discrepancy comes from.
Earlier quoted context omitted.
Python 3 paved the path for the changes that you mentioned you wished for, some of which are being tackled now. It's not only about what Python 3 offered at the time, but also about what it made possible in the long run.
How does print-as-function help anyone remove the GIL?
Earlier quoted context omitted.
> "Python 3.3: Trust Me, It's Better than 2.7" The fact that such a talk exists shows that the improvements aren't worth the switch for most users. If they were, they wouldn't need convincing. Yes, Python 3 is (mostly) better than Python 2. No, it's not even remotely worth the amount of confusion and work it caused. If Python 3 had brought massive performance improvements, or proper support for multiple threads, then…
> No, it's not even remotely worth the amount of confusion and work it caused. Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of m…
There’s no need to sugar coat it.
It was incompetently managed, in a way that made the technical success of the work look like a failure.
That’s on them. They screwed up.
I lived through it; I feel no particular need to smile and nod and say “it wasn’t that bad”. It was bad.
Things are good now! Python 3 is great, it’s well supported and the people involved all learnt a lot about how important managing communities is, as well as writing good code.
So, all round, a success!
…but, if you don’t acknowledge failures in the past, you’re doomed to repeat them.
> Now you might think that’s not important
I don’t think your experience with Python 2 is not important; I had similar issues with it.
No one is seriously going back to Python 2 at this point.
However, the process is a lesson worth studying; and the take away is not “what a technical success!”
… it is: never do this.
Big scary breaking migrations are bad, they hurt your community, and leave bitterness behind them.
Even if the result is better, technically; there are other factors that need to be considered too.
Earlier quoted context omitted.
It’s not that I don’t understand it. The problem is that encode and decode are directional constructs that change depending on context. That’s a poor UI in Python.
Genuinely curious, what would you like it to look like?
Earlier quoted context omitted.
At least they removed something that had been deprecated ERROR: gcloud failed to load: module 'collections' has no attribute 'Mapping'
That was a 3.8 change I think? It moved from collections to collections.abc, IIRC.
Earlier quoted context omitted.
> No, it's not even remotely worth the amount of confusion and work it caused. Have you worked with pervasively non-ASCII text in Python 2? Like on a machine where any file might suddenly turn out to be non-ASCII (even if it’s only in a comment), not just data inside a few carefully-patrolled fences? Outside of a few well-behaved libraries (Flask), my experience was that it was utterly impossible. More than half of m…
There is another universe where Python 3 only fixed the unicode strings, and the transition was a huge success and over in a couple of years. The print() function was absolutely not worth all the carnage it caused. They could have just kept the print statement around and introduced a printing function with a different name, for example. The fact that they removed syntax for Python 3 meant that all kinds of scientific…
Earlier quoted context omitted.
We had crazy amounts of code handling unicode support and conversion from our ecommerce site to our ERP system (running on Windows using some Windows code page thing). With Python 3 all that went away, you can now just seamlessly parse text from one system to another. For me, the unicode handling alone was worth the time spend migrating from Python 2. That was a decade ago, to finding that the "python" command still…
> finding that the "python" command still launches a Python 2.7 apt install python-is-python3
Earlier quoted context omitted.
A lot of codebases could be converted from Python 2 to Python 3 with just some fairly mechanical work and light refactoring on top. GIL would be a thing of a completely different magnitude.
It’s so trivial! All that needs to happen is someone else putting in the work. And for free, please!