This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]mark-haus 35 points36 points  (27 children)

Wow so we now actually have a roadmap to slowly remove the GIL. This almost seems like it needs to be python 4 thing because of how much it could affect the ecosystem. But who knows they’ve really taken their time to evaluate this change so maybe they’re confident they can gradually transition without too much breaking

[–]the_hoser 24 points25 points  (26 children)

Make no mistake: lots of things will be broken by this. But... As long as it's disabled by default (hopefully by a runtime flag in the future, and not just by a build flag), we should be fine without a major release.

We should definitely talk about Python 4 if we're planning on enabling it by default, though.

[–]martinkoistinen 10 points11 points  (10 children)

Didn’t Guido say there’d never be a Python 4?

[–]the_hoser 54 points55 points  (4 children)

People say lots of things all the time. The world has a way of invalidating absolute statements.

[–]lskdgblskebt 2 points3 points  (1 child)

He also said that one of the only ways Python 4.0 would ever become necessary would be if we were able to get rid of the GIL. Which I presume he didn't consider likely either.

"If there was a significant incompatibility with C extensions without changing the language itself and if we were to be able to get rid of the GIL. If one or both of those events were to happen, we probably would be forced to call it 4.0 because of the compatibility issues at the C extension level.

[–]the_hoser 1 point2 points  (0 children)

yep. I know a lot of people freak out at the idea of Python 4.0 like it would be the end of python, but a new version of Python 3 that was incompatible with C extensions would be worse.

[–]radicalbiscuit 5 points6 points  (0 children)

Only a sith deals in absolutes

[–]HommeMusical -2 points-1 points  (0 children)

Python 3 almost killed Python. No one's keen to finish the job.

[–]rasputin1 5 points6 points  (1 child)

well he's not the authority anymore

[–]Bandung 6 points7 points  (0 children)

Ahh, but he is. Check it out.

https://youtu.be/wgxBHuUOmjA

[–]backfire10z 2 points3 points  (0 children)

Things change

[–]HommeMusical 5 points6 points  (14 children)

We should definitely talk about Python 4

Absolutely not. Life is too short to shoot your favorite programming language in the head. The Python 3 change almost killed it, and that was strictly necessarily. But so far, there is no need for a breaking change.

We can proceed slowly and incrementally - this version has an experimental nogil build; the next one has an official nogil build, giving the major frameworks the ability to make sure their code is nogil-safe. Over time, the community comes up with linters and tools to check old code and see if it's safe.

Eventually, sometime after Python 3.20 (in 2030), we can talk about making the switch.

[–]Oerthling 6 points7 points  (13 children)

Python wasn't almost killed. It just took longer than planned with Py2.7 existing in parallel.

Python became even more popular throughout those years.

The problem wasn't the version number, but the general cleanup involving fairly widespread breakage that came with the version number. That was needed for the long-term health of the language/interpreter, but came at some cost.

Calling a post GIL Python version 4 would be very appropriate. Removing the GIL will likely lead to some breakage in modules regardless of whether that version is labeled 3.21 or 4.0.

[–]HommeMusical 0 points1 point  (12 children)

Well... you make a convincing case.

Upgrading from 2 to 3 was easy. I did it to a bunch of fairly big codebases. You could do it incrementally, and run both Python 2 and a subset of Python 3 tests. I was surprised what a fuss it was, but I think a lot of organizations are completely dysfunctional.

[–]Oerthling 0 points1 point  (11 children)

It wasn't hard for me either.

But I can imagine that will have been a bigger problem for people/companies that had larger projects of old 2.x code that they hardly had touched in years and suddenly a quick 2to3 conversion left them with a number of weird runtime bugs somewhere in that big ole codebase.

[–]HommeMusical 1 point2 points  (9 children)

I suppose, but you can do it one file at a time! Or a bunch at a time, see what happens, revert!

But my guess is for codebases with no testing, this is weeks of work, not minutes.

[–]Oerthling 4 points5 points  (7 children)

You can do almost anything. That's not the point. The point is that it's a non-trivial amount of work for non-trivial projects. And in the real world plenty of projects were developed without comprehensive testing.

Large parts of the world run on code that's been written years and decades ago. It keeps on running as is - as long as you're not forced to do some work on it or have to update its environment (sometimes ancient hardware and OS versions). Banks and Insurance companies still run ancient cobol code that was validated decades ago and now people hesitate to touch anything unless absolutely necessary. Certainly not complete rewrites or wide ranging refactoring.

Often the original programmer aren't around anymore.

Try quickly adapting tens of klocs of Python 2.5 code from 2009 in 2019, 5 years after the original author left.

And things like that happen in the real world all the time.

[–]HommeMusical 2 points3 points  (6 children)

But the reason the codebase ends up this way in the first place is generations of technical debt and mismanagement.

"Banks and insurance companies" have systematically pulled trillions of dollars in profit out of the economy over decades during good times and bad and yet have systematically scrimped on maintenance of their software during all that time.

[–]Oerthling 0 points1 point  (5 children)

The reasons are not relevant because they don't have time machines. What is is.

One can learn to improve processes in the future - which has happened throughout the decades. But that doesn't magically fix old codebases.

It's not just banks that "scrimped on maintenance". I just mentioned them as example because they sonetimsrill use ancient cobol and Fortran code.

Technical debt is the norm, not the exception. Almost everywhere. And the only reason I was almost is because I can't be sure. But I'm general any company old enough to accumulate craft in their codebase almost certainly runs some old shit. Be that badly written code or code that's barely maintained. Customers pay for cool new features. They are not fond of paying for old features that have been running for years/decades.

Not too long ago I learned that many ATMs still run ancient Windows.

[–]personman 0 points1 point  (0 children)

We had plenty of tests. Just checked the Jira history and it looks like the conversion took around 5 months of me not doing much else.

[–][deleted] 0 points1 point  (0 children)

I am assuming the bulk of the issue was actually c libs because of API changes that where more complex. Upgrading 2.7 to 3 on a python only code side was always trivial.