7 ms·

Are you referring to the Python 2 -> 3 fiasco? If so, I think that the Python language committee will never make such a mistake again. They've seen first-hand

by Cyph0n 7y ago

Are you referring to the Python 2 -> 3 fiasco? If so, I think that the Python language committee will never make such a mistake again. They've seen first-hand how difficult it is to get the ecosystem to move forward after a breaking change like that. But within Python 3, I think the deprecation system is decent. As far as I know, it really only occurs with "uncommon" APIs, so the vast majority of code will continue to work as expected on later Python 3 versions.

AlexeyBrin 7y ago
> But within Python 3, I think the deprecation system is decent. As far as I know, it really only occurs with "uncommon" APIs, so the vast majority of code will continue to work as expected on later Python 3 versions. The problem is that every new Python version seems to break something. Python 3.8 was released almost two weeks ago, and some popular libraries still don't work with it, e. g. SciPy, Matplotlib, OpenCV, PyQt, PySide2 and probably a bunch of other libraries that depend on the above.
- jacquesm 7y ago
  Which is just about everything outside of Keras/Tensorflow that I use. Highly frustrating. Languages should be designed with backwards compatibility in mind right from day #1. Porting code isn't free.
willis936 7y ago
Mostly, yes, as I’m responsible for a data acquisition system written 10 years ago. “Just” getting to python 3 is a massive effort which would first require getting to 2.7 from 2.5, which itself would be a time consuming task. I’m starting to think the best solution would be to just stay on python 2.5. Updates to software should not be the implementer’s tormentor.
- 3JPLW 7y ago
  Then this is an unfair critique of this new release process. If you had issues with breaking changes between minor 3.x versions, then I'd fully understand.
  - willis936 7y ago
    Are complaints about things breaking between 2.x versions somehow invalid? It’s the same steering group that has made a series of breaking changes. Even people on branches of this thread claim there are breaking changes in 3.7 > 3.8. I’m not sure I would willingly use python for any new project unless necessary, putting it into the same bin as national instruments.
    - vcxy 7y ago
      It's a valid complaint on it's own, sure. But it kind of looks like you're complaining that they're going from an ~18 month cycle to a scheduled 12 month cycle. It's not really valid as a complain for this particular change. You're talking about a decade. 18 months vs 12 months seems inconsequential for you.
      - willis936 7y ago
        I'm complaining about the ethos of the python maintainers. I don't see how putting out updates more rapidly will do anything to my complaints other than make future me dislike using python even more. At first I thought they missed a beat but now I think they're playing free jazz.
        3JPLW 7y ago
        The 3.x releases _are nothing like_ the 3.0 release. You have a valid complaint about the 3.0 release, which was 11 years ago. If you've not tried updating from 3.x to 3.y — which is a very different process — then you have no stake in this change.
- icegreentea2 7y ago
  It's your call to make. If your system doesn't have some sort of 'security' risk to it, then all the reasons you have to upgrade are purely internal cost-benefit analysis. Code is a tool, treat it like any other. Just be aware of possible accumulating deferred costs. I don't know exactly what field your in, but just imagine any other piece of equipment or component going EOL, and the manufacturer only providing semi-drop in replacements. Or even if they are advertised as "drop in", you know that half the time they aren't, and something derpy happens on integration.
  - willis936 7y ago
    The system is not firewalled from the internet. There are tools that need internet based licenses. There are organization firewalls, but there is always a risk involved with having unpatched platforms. I have to weigh that risk against the cost of porting. Both are difficult to gauge.
    - icegreentea2 7y ago
      How are the Python 2.5 components being invoked? Are they python processes that are constantly running? Or are they jobs spun up by other processes?
      - willis936 7y ago
        Oh they’re always running and on dozens of machines.
- acdha 7y ago
  If you still haven't upgraded from a version released 13 years ago to one released 9 years ago, what difference does a slightly faster release tempo make? If it's that much work, something else has gone wrong in the software development process and all the Python upgrades are doing is making that failure harder to ignore.
mikepurvis 7y ago
I think there's also an effect where some of us have gotten used to Python 2.7.x being utterly predictable and unchanging for like, the decade since it came out. It's not Python's fault, but for example I was trying to get something running on Ubuntu 16.04 (Python 3.5) where the primary developer of it is running Ubuntu 18.04 (Python 3.6), and it seems like 3.5's version of the asyncio module has a bunch of bugs that make the tool in question basically unusable. I know the usual advice— install newer Python from deadsnakes, use a virtualenv, etc. None of this stuff is the end of the world, but it can be jarring if you're only now getting off the Python 2.7 train and used to everything just working everywhere.
- kstrauser 7y ago
  That's not really fair, though. If the developer were writing it on 2.7 and you were running it on 2.6, I wouldn't hold that against Python 2.
  - mikepurvis 7y ago
    Oh I completely acknowledge that. This is less about Python and more "fast moving platform" vs "slow moving platform".
- takeda 7y ago
  well asyncio was introduced in 3.5 though, it just happened that initial version was buggy and you should assume asyncio is available since 3.6 (or actually 3.5.3+)
kstrauser 7y ago
I don't think it was a mistake. There were some intractably difficult, "rip-the-band-aid-off" types of changes that had to happen at some point. The PSF decided that 3.0 was the right time to make those one-time changes so that future migrations could be as small as possible.
- cft 7y ago
  Then why didn't they remove GIL? Given the end of Moore's law and Python's performance, this alone would have justified the discontinuity.
  - fiedzia 7y ago
    Because GIL is useful, preventing you from shooting yourself terribly in the foot among other benefits. Languages with better concurrency support (main reason for removing GIL) were designed from scratch for that purpose. You can't remove GIL and keep Python being Python everyone knows. And if you don't mind using another language, there are many choices.
    - laurencerowe 7y ago
      I believe Jython offers the same level of protection against shooting yourself in the foot as CPython, yet it allows allows for parallel execution by relying on finer grained locking. The concurrency issues with threads are still present in CPython with the GIL as the interpreter may switch threads between any instruction.
  - kstrauser 7y ago
    There've been various attempts at this over the years, but it's really orthogonal to changes to the language itself. Also, check out the SharedMemory objects[1] in 3.8. For my own use cases, this goes a long way toward making me no longer care about the GIL. I'd rather work on multiprocessing code than multithreaded code any time, and if you can easily share objects across processes, then the GIL isn't relevant to anything I'm working on. [1] https://docs.python.org/3/library/multiprocessing.shared_memory.html#multiprocessing.shared_memory.SharedMemory https://docs.python.org/3/library/multiprocessing.shared_mem...
pletnes 7y ago
How was it a fiasco? The old version was supported for free for what, a decade? Usage of python is skyrocketing. I don’t know anyone who honestly prefer 2 over 3. The number of python packages released in one year now is probably higher than that of all years combined up to the release of python 3. The process was not perfect, but in my book it’s a success.
- 3JPLW 7y ago
  It was a fiasco because it wasn't possible (until much later) to support both Python 2 and Python 3 in the same code base. This made for a gridlock between dependencies and users.
  - aroberge 7y ago
    This is a misconception that has likely been compounded by the initial advice (by core Python folks, who eventually reverted their stance) on not doing this. For example, see this blog post https://aroberge.blogspot.com/2009/08/crunchy-10-released.html https://aroberge.blogspot.com/2009/08/crunchy-10-released.ht... from 2009 for a non-trivial program that supported Python 2.4, 2.5, 2.6 and 3.1. It was a bit of a pain as it dealt with lots of unicode/strings, but it was doable. It became easier to support both Python 2 and Python 3 later on, especially once Python 3.2 was released.
    - 3JPLW 7y ago
      Ok, sorry, replace "not possible" with "very difficult and not recommended." I don't see how that changes what I wrote in a very meaningful way.

by Cyph0n 7y ago

AlexeyBrin 7y ago

> But within Python 3, I think the deprecation system is decent. As far as I know, it really only occurs with "uncommon" APIs, so the vast majority of code will continue to work as expected on later Python 3 versions. The problem is that every new Python version seems to break something. Python 3.8 was released almost two weeks ago, and some popular libraries still don't work with it, e. g. SciPy, Matplotlib, OpenCV, PyQt, PySide2 and probably a bunch of other libraries that depend on the above.

jacquesm 7y ago
Which is just about everything outside of Keras/Tensorflow that I use. Highly frustrating. Languages should be designed with backwards compatibility in mind right from day #1. Porting code isn't free.

willis936 7y ago

Mostly, yes, as I’m responsible for a data acquisition system written 10 years ago. “Just” getting to python 3 is a massive effort which would first require getting to 2.7 from 2.5, which itself would be a time consuming task. I’m starting to think the best solution would be to just stay on python 2.5. Updates to software should not be the implementer’s tormentor.

3JPLW 7y ago
Then this is an unfair critique of this new release process. If you had issues with breaking changes between minor 3.x versions, then I'd fully understand.
- willis936 7y ago
  Are complaints about things breaking between 2.x versions somehow invalid? It’s the same steering group that has made a series of breaking changes. Even people on branches of this thread claim there are breaking changes in 3.7 > 3.8. I’m not sure I would willingly use python for any new project unless necessary, putting it into the same bin as national instruments.
  - vcxy 7y ago
    It's a valid complaint on it's own, sure. But it kind of looks like you're complaining that they're going from an ~18 month cycle to a scheduled 12 month cycle. It's not really valid as a complain for this particular change. You're talking about a decade. 18 months vs 12 months seems inconsequential for you.
    - willis936 7y ago
      I'm complaining about the ethos of the python maintainers. I don't see how putting out updates more rapidly will do anything to my complaints other than make future me dislike using python even more. At first I thought they missed a beat but now I think they're playing free jazz.
      - 3JPLW 7y ago
        The 3.x releases _are nothing like_ the 3.0 release. You have a valid complaint about the 3.0 release, which was 11 years ago. If you've not tried updating from 3.x to 3.y — which is a very different process — then you have no stake in this change.
icegreentea2 7y ago
It's your call to make. If your system doesn't have some sort of 'security' risk to it, then all the reasons you have to upgrade are purely internal cost-benefit analysis. Code is a tool, treat it like any other. Just be aware of possible accumulating deferred costs. I don't know exactly what field your in, but just imagine any other piece of equipment or component going EOL, and the manufacturer only providing semi-drop in replacements. Or even if they are advertised as "drop in", you know that half the time they aren't, and something derpy happens on integration.
- willis936 7y ago
  The system is not firewalled from the internet. There are tools that need internet based licenses. There are organization firewalls, but there is always a risk involved with having unpatched platforms. I have to weigh that risk against the cost of porting. Both are difficult to gauge.
  - icegreentea2 7y ago
    How are the Python 2.5 components being invoked? Are they python processes that are constantly running? Or are they jobs spun up by other processes?
    - willis936 7y ago
      Oh they’re always running and on dozens of machines.
acdha 7y ago
If you still haven't upgraded from a version released 13 years ago to one released 9 years ago, what difference does a slightly faster release tempo make? If it's that much work, something else has gone wrong in the software development process and all the Python upgrades are doing is making that failure harder to ignore.

mikepurvis 7y ago

I think there's also an effect where some of us have gotten used to Python 2.7.x being utterly predictable and unchanging for like, the decade since it came out. It's not Python's fault, but for example I was trying to get something running on Ubuntu 16.04 (Python 3.5) where the primary developer of it is running Ubuntu 18.04 (Python 3.6), and it seems like 3.5's version of the asyncio module has a bunch of bugs that make the tool in question basically unusable. I know the usual advice— install newer Python from deadsnakes, use a virtualenv, etc. None of this stuff is the end of the world, but it can be jarring if you're only now getting off the Python 2.7 train and used to everything just working everywhere.

kstrauser 7y ago
That's not really fair, though. If the developer were writing it on 2.7 and you were running it on 2.6, I wouldn't hold that against Python 2.
- mikepurvis 7y ago
  Oh I completely acknowledge that. This is less about Python and more "fast moving platform" vs "slow moving platform".
takeda 7y ago
well asyncio was introduced in 3.5 though, it just happened that initial version was buggy and you should assume asyncio is available since 3.6 (or actually 3.5.3+)

kstrauser 7y ago

I don't think it was a mistake. There were some intractably difficult, "rip-the-band-aid-off" types of changes that had to happen at some point. The PSF decided that 3.0 was the right time to make those one-time changes so that future migrations could be as small as possible.

cft 7y ago
Then why didn't they remove GIL? Given the end of Moore's law and Python's performance, this alone would have justified the discontinuity.
- fiedzia 7y ago
  Because GIL is useful, preventing you from shooting yourself terribly in the foot among other benefits. Languages with better concurrency support (main reason for removing GIL) were designed from scratch for that purpose. You can't remove GIL and keep Python being Python everyone knows. And if you don't mind using another language, there are many choices.
  - laurencerowe 7y ago
    I believe Jython offers the same level of protection against shooting yourself in the foot as CPython, yet it allows allows for parallel execution by relying on finer grained locking. The concurrency issues with threads are still present in CPython with the GIL as the interpreter may switch threads between any instruction.
- kstrauser 7y ago
  There've been various attempts at this over the years, but it's really orthogonal to changes to the language itself. Also, check out the SharedMemory objects[1] in 3.8. For my own use cases, this goes a long way toward making me no longer care about the GIL. I'd rather work on multiprocessing code than multithreaded code any time, and if you can easily share objects across processes, then the GIL isn't relevant to anything I'm working on. [1] https://docs.python.org/3/library/multiprocessing.shared_memory.html#multiprocessing.shared_memory.SharedMemory https://docs.python.org/3/library/multiprocessing.shared_mem...

pletnes 7y ago

How was it a fiasco? The old version was supported for free for what, a decade? Usage of python is skyrocketing. I don’t know anyone who honestly prefer 2 over 3. The number of python packages released in one year now is probably higher than that of all years combined up to the release of python 3. The process was not perfect, but in my book it’s a success.

3JPLW 7y ago
It was a fiasco because it wasn't possible (until much later) to support both Python 2 and Python 3 in the same code base. This made for a gridlock between dependencies and users.
- aroberge 7y ago
  This is a misconception that has likely been compounded by the initial advice (by core Python folks, who eventually reverted their stance) on not doing this. For example, see this blog post https://aroberge.blogspot.com/2009/08/crunchy-10-released.html https://aroberge.blogspot.com/2009/08/crunchy-10-released.ht... from 2009 for a non-trivial program that supported Python 2.4, 2.5, 2.6 and 3.1. It was a bit of a pain as it dealt with lots of unicode/strings, but it was doable. It became easier to support both Python 2 and Python 3 later on, especially once Python 3.2 was released.
  - 3JPLW 7y ago
    Ok, sorry, replace "not possible" with "very difficult and not recommended." I don't see how that changes what I wrote in a very meaningful way.