5 ms·

I know they say specifically that they don't want a repeat of the Python3 transition scenario, but the approach they're taking now still veers eerily close to t

by tremon 3y ago

I know they say specifically that they don't want a repeat of the Python3 transition scenario, but the approach they're taking now still veers eerily close to that path, at least it looks that way to me. A lot will depend on the Python community and the distribution channels. I could see the community struggling to adopt it in a timely fashion, or distributions jumping the gun (Ubuntu, Fedora, Anaconda). Maybe it's too early to make hard decisions, but how much control does the SC really have to avoid such a scenario?

trwsxcn 3y ago
Yes, it will resemble the 2to3 scenario. Corporations that pledge support will mechanically convert some projects (pestering the actual developers or threaten with forks?), bugs will be ironed out by the actual, unpaid developers over years. But apparently Python needs some "success" and this makes a good bullet point. Correctness does not really matter in the Python world.
- miraculixx 3y ago
  Is it success though?
a_nop 3y ago
They kind of burned a breaking major version transition for no good reason with 2-to-3, now they are prefacing a major change with "it won't be like 2-to-3". It sounds like they may be maintaining two operating modes in CPython 3 instead of going forward with another major transition, just because of that history.
- jborean93 3y ago
  > They kind of burned a breaking major version transition for no good reason with 2-to-3 The unicode/text changes alone were a pretty good reason. Division producing floats are also a nice change IMO. I don’t want to discount the challenges with the transition but saying there was no good reason isn’t right to me.
  - rightbyte 3y ago
    Not good enough reason then?
  - lozenge 3y ago
    There were a lot of bad reasons as well. The removal of the u string prefix in versions 3.0-3.2 was unnecessary and made the transition much more difficult. It kind of gave Python 3 a bad reputation.
  - a_nop 3y ago
    Unicode was absolutely a good change, the burn was the execution
gary_0 3y ago
They say they want no-gil to be the only build mode 5 years from when it becomes available. That is both too long and too short. That is too long for Python to have 2 modes. Half a decade is more than enough time for 2 modes to become the status quo. For one thing, think of all the outdated Stackoverflow threads that will be hanging around after that 5 years. I am not optimistic that 5 years won't turn into 10 years of uncertainty and breakage. But 5 years might be too short for everyone to dredge up all that C code, update it, test it, and call it mature. I guess we'll see.
- toyg 3y ago
  > 5 years might be too short for everyone to dredge up all that C code, update it, test it, and call it mature. Developers are lazy. Most people will just do nothing until, 5 years from now, some blog post will go "oh, next month we switch noGil as default, good luck!". At that point everyone will scramble, rush out buggy releases, and spend 5 years finding all the problems.
  - lozenge 3y ago
    The no-gil "build mode" will still have the ability to switch to GIL "run mode", it will just be slower than the GIL run mode on the GIL build mode. Hopefully not much slower.

by tremon 3y ago

trwsxcn 3y ago

Yes, it will resemble the 2to3 scenario. Corporations that pledge support will mechanically convert some projects (pestering the actual developers or threaten with forks?), bugs will be ironed out by the actual, unpaid developers over years. But apparently Python needs some "success" and this makes a good bullet point. Correctness does not really matter in the Python world.

miraculixx 3y ago
Is it success though?

a_nop 3y ago

They kind of burned a breaking major version transition for no good reason with 2-to-3, now they are prefacing a major change with "it won't be like 2-to-3". It sounds like they may be maintaining two operating modes in CPython 3 instead of going forward with another major transition, just because of that history.

jborean93 3y ago
> They kind of burned a breaking major version transition for no good reason with 2-to-3 The unicode/text changes alone were a pretty good reason. Division producing floats are also a nice change IMO. I don’t want to discount the challenges with the transition but saying there was no good reason isn’t right to me.
- rightbyte 3y ago
  Not good enough reason then?
- lozenge 3y ago
  There were a lot of bad reasons as well. The removal of the u string prefix in versions 3.0-3.2 was unnecessary and made the transition much more difficult. It kind of gave Python 3 a bad reputation.
- a_nop 3y ago
  Unicode was absolutely a good change, the burn was the execution

gary_0 3y ago

They say they want no-gil to be the only build mode 5 years from when it becomes available. That is both too long and too short. That is too long for Python to have 2 modes. Half a decade is more than enough time for 2 modes to become the status quo. For one thing, think of all the outdated Stackoverflow threads that will be hanging around after that 5 years. I am not optimistic that 5 years won't turn into 10 years of uncertainty and breakage. But 5 years might be too short for everyone to dredge up all that C code, update it, test it, and call it mature. I guess we'll see.

toyg 3y ago
> 5 years might be too short for everyone to dredge up all that C code, update it, test it, and call it mature. Developers are lazy. Most people will just do nothing until, 5 years from now, some blog post will go "oh, next month we switch noGil as default, good luck!". At that point everyone will scramble, rush out buggy releases, and spend 5 years finding all the problems.
- lozenge 3y ago
  The no-gil "build mode" will still have the ability to switch to GIL "run mode", it will just be slower than the GIL run mode on the GIL build mode. Hopefully not much slower.