Hacker News Reader

Comment by tremon | Hacker News Reader

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?

View on HN

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.

> 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.

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.

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.

Is it success though?

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.

> 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.

Not good enough reason then?

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.

Unicode was absolutely a good change, the burn was the execution

Reply on news.ycombinator.com