Our Plan for Python 3.13

https://github.com/faster-cpython/ideas/blob/main/3.13/README.md

by bratao • 3 years ago

531 388 3 years ago

github.com

klooney• 3 years ago

This is exciting. Feels a little like JavaScript 10 years ago.

andai• 3 years ago

You mean 15? ;) https://en.wikipedia.org/wiki/V8_(JavaScript_engine)

samwillis5• 3 years ago

The "Faster Python" team are doing a fantastic job, it's incredible to see the progress they are making.

However, there is also a bit of a struggle going on between them and the project to remove the GIL (global interpreter lock) from CPython. There is going to be a performance impact on single threaded code if the "no GIL" project is merged, something in the region of 10%. It seems that the faster Python devs are pushing back against that as it impacts their own goals. Their argument is that the "sub interpreters" they are adding (each with its own GIL) will fulfil the same use cases of multithreaded code without a GIL, but they still have the overhead of encoding and passing data in the same way you have to with sub processors.

There is also the argument that it could "divide the community" as some C extensions may not be ported to the new ABI that the no GIL project will result in. However again I'm unconvinced by that, the Python community has been through worse (Python 3) and even asyncIO completely divides the community now.

It's somewhat unfortunate that this internal battle is happening, both projects are incredible and will push the language forward.

Once the GIL has been removed it opens us all sorts of interesting opportunities for new concurrency APIs that could enable making concurrent code much easer to write.

My observation is that the Faster Python team are better placed politicly, they have GVR on the team, whereas No GIL is being proposed by an "outsider". It just smells a little of NIH syndrome.

bratao2• 3 years ago

Yeah, they clearly stated that here https://discuss.python.org/t/pep-703-making-the-global-inter...

I really wish that GIL go away. It is better to pay this price now, multi-threading is the future.

hospitalJail4• 3 years ago

I'm so conflicted.

~40 of the programs I am responsible for are single threaded. They were relatively quick to develop and were made by Electrical Engineers rather than career/degreed programmers.

2 programs use multithreading, I had to do that. The learning curve was not a huge deal, but the development time adds at least hours. In my case days(due to testing).

I imagine its too hard to have an optional flag at the start of each program that can let the user decide?

sgt• 3 years ago

Not for Python, I feel. In sheer volume, the vast majority of my Python programs are single-threaded. I want my programs to be very quick in runtime when they run.

Those that are multi-threaded are seeing minor to medium load.

If expecting extreme load (like Twitter scale), then Python is usually not the answer (rather go to a statically typed language like Java, Go, Rust etc).

amelius5• 3 years ago

It's relatively simple to make the GIL go away: just compile to some VM that has a good concurrent garbage collector would be one approach. Yes, this will break some assumptions here and there, but not too difficult to overcome especially if you bump the version number to Python 4.

However, that leaves a lot of C code that you can't talk to anymore because the C code requires the old Python FFI. I think this is where the main problem lies.

PhilipRoman• 3 years ago

multi-threading is the future

Haha, reminds me of an image I saw with a farmer from some developing country saying "irrigation is the future".

For everyone else multithreading has been the status quo for quite a long time.

ActorNightly5• 3 years ago

multi-threading is the future.

Yes, with ML powered compilers recognizing what you are trying to do and generating the actual multithreaded code for you.

And it won't be multithreaded code like you know it, in the sense of os specific threading code with context switching and what not. It will be compiled compute graphs targeted at specific ML hardware, likely with static addressing.

vb-84482• 3 years ago

There is going to be a performance impact on single threaded code if the "no GIL" project is merged, something in the region of 10%.

10% doesn't look too much to me, I still don't get why today people care so much about single thread performance.

samwillis5• 3 years ago

Exactly, and the thing is, the Faster Python project will completely surpass that 10% performance change.

awill• 3 years ago

because a lot of code is single-threaded

celeritascelery5• 3 years ago

Single threaded performance is still more important than multi-threaded. Most applications are single threaded, and single threaded programs are much easier to write and debug. Removing the GIL from python will not change that.

If no-GIL has a 10% single thread performance hit, that means that essentially all my existing python code would be that much worse.

ahoho• 3 years ago

Right, and single thread performance won’t matter as much if it becomes easier to implement multithreading. This hurts legacy code, but I imagine it would be worth it in the long run.

hospitalJail4• 3 years ago

I still don't get why today people care so much about single thread performance.

For about 10 minutes a few years ago, when the M1 had the best single threaded performance per buck, people cared.

Now that the M1 isnt the leader in single threaded, we are back to the 'multithread is most important'.

Which has always been true. If your program needs an improvement in speed, you can multithread it. The opposite isnt true.

david422• 3 years ago

And if you're really concerned about speed, Python is not the language to choose.

crabbone• 3 years ago

CPython is so hopelessly slow, I wouldn't care about 10%. For most of the stuff written in Python, users don't really care about speed.

The impact won't be on users / Python programmers who don't develop native extensions. It will suck for people who had a painful workaround for Pythons crappy parallelism already, but now will have to have two workarounds for different kinds of brokenness. It still pays off to make these native extensions, however their authors will create a lot of problems for the clueless majority of Python users, which will like end up in some magical "workarounds" for problems introduced by this change very few people understand. This will result in more cargo cult in the community that's already on the witch hunt.

meepmorp• 3 years ago

There is also the argument that it could "divide the community" as some C extensions may not be ported to the new ABI that the no GIL project will result in. However again I'm unconvinced by that, the Python community has been through worse (Python 3) and even asyncIO completely divides the community now.

I think the fact that you can name two other recent things which have divided the community is a solid argument for being a least a little gunshy about making big, breaking changes. There's the cost of the changes themselves, but there's also a cost to the language as a whole to add yet-another-upheaval.

Performance is important, but not breaking things is also important. I can understand the appeal of doing something suboptimal (but better than current) in favor of not introducing a bunch of harder to predict side effects, both in code and the community.

deschutes• 3 years ago

Do sub interpreters actually work with c extensions? I get the extension API has long supported it. However, I wonder if in practice extensions rely on process global state to stash information.

If so, sub interpreters invite all kinds of nasty bugs. Keep in mind that porting the most popular extensions is an easy exercise so the more interesting question is how this hidden majority of extensions fares.

p5a0u9l• 3 years ago

Removing the GIL should be seen as a last option.

matsemann• 3 years ago

GIL is one of the things that make Python an annoyance to work with. In saner languages, you could handle multiple requests at the same time, or easily spin something off in a thread to work in the background. In Python you can't do this. You need to duplicate your process, then pay the price of memory usage and other things multiple processes hinder (like communication between threads or pre-computed values now aren't shared so you need something external again). To deploy your app, you end up with 10 different deploys because each of them have to have a different entry point and separate task to fulfill.

stinos2• 3 years ago

GIL is one of the things that make Python an annoyance to work with

For your particular usecase, yes. Personally I've been using Python for like 20 years for various tasks and so far never got really bothered by the presence of it once. Worst case was having to wait somewhat longer for things to complete. For my case: still worth it compared to making things multithreaded. And async fixed the rest. And the things which I actually need to be fast aren't usually in Python anyway. I'm not saying the GIL should stay, it's just that it doesn't seem as much of a problem in the general land of Python. Or in other words: how many Python users out there even know what GIL means and does?

paulddraper4• 3 years ago

Other languages do that: JavaScript, PHP, Erlang.

Python multiprocessing is pretty usable.

I like multithreading, but also...it has more footguns then the rest of programming combined. [1]

I'm not convinced Python's approach is that bad in practice.

[1] https://news.ycombinator.com/item?id=22165193

ActorNightly5• 3 years ago

The other languages are not saner. You are basically saying "Python GIL is annoying because I can't write parallel processing performant code in Python". Python has never been and is not a performant language. Its designed for rapid and easy development.

The multiprocessing+asyncio in Python fulfills the aspect of utilizing all the resources, albeit at a higher memory cost, but memory is dirt cheap these days. You have a master process and then worker threads. For all things that you would write in Python, where in >90% cases you are network latency limited, the paradigm of a master process and worker processes with IPC on unix sockets works extremely well. Set up a web app with fast api/gunicorn master/uvicorn workers, and it will be plenty fast enough for anything you do.

oconnor663• 3 years ago

you could handle multiple requests at the same time

To be fair to Python and the GIL, it's totally capable of parallelizing requests when most of the work is network-bound, which is probably the common case. And when the work is CPU-bound, but the CPU-intensive part is written in C, it's also possible for C to release the GIL. So it's really only "heavy computational work directly in Python" programs that are affected by this. (On the other hand, Python applications do naturally expand to look like this over time...)

slt2021• 3 years ago

No it is not.

If you want to reach peak performance single-threaded app with no locks is the way to go, and work being sharded (not shared) among multiple single-threaded apps.

Multi-threaded apps with shared state introduce more complexity, than the performance when compared to multiple single-threaded apps running asyncio event loop.

For example LMAX Disruptor

gnulinux5• 3 years ago

This is your opinion, but many disagree. I personally find processes infinitely easier to deal with than thread, it's not even a discussion in my mind. For me, threads are banned from usage, until it's absolutely necessary to do so. When I write code in C++ there are cases where a problem cannot be solved unless threads are used. It's fine to use threads there. For everything else I appeal to either multiprocessing or `async` concurrency.

hgs3• 3 years ago

You need to duplicate your process, then pay the price of memory usage ...

I believe the implementation of the Python multiprocessing package uses fork() on *nix systems which means memory should be copy-on-write.

Processes do have the advantage of being self-contained meaning if one crashes, then it will not take down the entire system. Also, the message passing model can theoretically scale to processes running on separate hardware. Thread's cannot do that.

RobotToaster• 3 years ago

Why not just try to make multiprocessing easier?

gazpacho• 3 years ago

The other thing I don't get is that the whole sub interpreters thing seems to totally break extension modules as well: https://github.com/PyO3/pyo3/issues/2274. In theory parts of sub-interpreters have been around for a while and it just happens that every extension module out there is incompatible with it because no one used it. But if it's going to become the recommended way to do parallelism going forward then they'll have to become compatible with it.

The serialization thing is also a huge issue. Half of the time I want to use multiprocessing I end up finding that the serialization of data is the bottleneck and have to somehow re-architect my code to minimize it.

I would much prefer a world in which asyncio is 2x faster and can benefit from real parallelism across threads. Libraries like anyio already make it super easy to work with async + threads. It would make Python a viable option for workloads where it currently just isn't.

rogerbinns• 3 years ago

(Disclosure: Author of a Python C extension that wraps SQLite that has 2 decades of development behind it.)

Have a look at the current documentation for writing extensions. This approach is essentially unchanged since Python 2.0. https://docs.python.org/3/extending/newtypes_tutorial.html

In particular note how everything is declared static - ie only one instance of that data item will exist. If there are multiple interpreters then there needs to be one instance per sub-interpreter. That means no more static and initialisation has to be changed to attach these to the module object which is then attached to a specific interpreter instance. It also means every location you needed to access a previously static item (which often happens) has to change from a direct reference through new APIs chasing back from objects to get their owning module and then get the reference. That is the code churn the PyO3 issue is having to address. One bonus however is that you can then cleanly unload modules.

This may still not be sufficient. For example I wrap SQLite and it has some global items like a logging callback. If my module was loaded into two different sub interpreters and both registered the logging callback, only one would win. These kind of gnarly issues are hard to discover and diagnose.

Removing the GIL also won't magically help. I already release it at every possible opportunity. If it did go away, I would have to reintroduce a lock anyway to prevent concurrency in certain places. And there would have to be more locking around various Python data structures. For example if I am processing items in a list, I'd need a lock to prevent the list changing while processing. Currently the GIL handles that and ensures fewer bugs.

I've also experienced the serialization overhead with multiprocessing. I made a client's code so much faster that any form of Python concurrency was slower because of all the overhead. I had to rearchitect the code to work on batches of data items instead of the far more natural one at a time. That finally allowed a performance improvement with multiprocessing.

dekhn2• 3 years ago

The GIL will never be removed from the main python implementation. Histortically, the main value of GIL removal proposals and implementations has been to spur the core team to speed up single core codes.

I think it's too late to consider removing the gil from the main implementation. Like guido said in the PEP thread, the python core team burned the community for 10 years with the 2-3 switch, and a GIL change would be likely as impactful; we'd have 10 years of people complaining their stuff didn't work. Frankly I wish Guido would just come out and tell Sam "no, we can't put this in cpython. You did a great work but compatibility issues trump performance".

Kind of a shame because Hugunin implemented a Python on top of the CLR some 20 years ago and showed some extremely impressive performance results. Like jython, and pypy and other implementations, it never caught on because compatibility with cpython is one of the most important criteria for people dealing with lots of python code.

giantrobot2• 3 years ago

Like jython, and pypy and other implementations, it never caught on because compatibility with cpython is one of the most important criteria for people dealing with lots of python code.

I think this is more an issue of popular packages were developed and tested against cpython and there wasn't enough effort available to port/test them against anything else. There's no special magic in cpython that Python programmers love, they just want their code to run. If they've got a numpy dependency (IIRC it doesn't support pypy but I'm not going to look it up so I may be corrected on that point this is a long parenthetical) they can't use an interpreter that doesn't support it. Even if it worked but had bugs it didn't have in cpython, they're still going to use cpython. Most people aren't writing Python for its super duper fast performance so they're fine leaving a little performance on the table by using the interpreter that their dependencies support. Whatever that is.

coldtea17• 3 years ago

the python core team burned the community for 10 years with the 2-3 switch, and a GIL change would be likely as impactfu

A core team led by him, which also had the opportunity to make much more impactful changes during 3, including removing the GIL, since they were going to mess up compatibility anyway, but didn't.

All that mess (and resulting split and multi-year slowdown in Py3 adoption) just to put in the utf-8 change and some trivial changes. It's only after 3.5 or so that 3 became interesting.

jedberg3• 3 years ago

The GIL will never be removed from the main python implementation.

I don't see why. It's a much easier transition than 2 to 3.

Make each package declare right at the top if they are non-GIL compatible. Have both modes available in the interpreter. If every piece of code imported has the declaration on top, then it runs in non-GIL mode, otherwise it runs in classic GIL mode.

At first most code would still run in GIL mode, but over time most packages would be converted, especially if people stopped using packages that weren't compatible.

Dork1234• 3 years ago

I really think the GIL is saving a bunch of poorly written multi-threaded C++ wrappers/libraries out there. If they remove it, a bunch of bugs will appear in other libraries that might not be Pythons fault.

zackees• 3 years ago

I agree with this take.

The GIL is hiding all kinds of concurrency bugs. If the CPython team default disable it then all hell is going to break loose.

It's better to carve out special concurrency constructs for those that need it.

lacker• 3 years ago

I think it's too late to consider removing the gil from the main implementation.

I think it'll happen one day. Is Python going anywhere?

Give it 20 years. The 2 -> 3 switch will be like the Y2K bug, only remembered by the oldest programmers. The memories of pain will fade, leaving only entertaining war stories. The GIL will still be there, and still be annoying.

Then, when everyone has forgotten, the community will be ready. For an incredibly long and grinding transition to Python 4.

londons_explore• 3 years ago

compatibility issues trump performance".

Surely it would be possible to drop back to GIL mode if any c extension is loaded which is incompatible with running lockless?

Then you usually get speed, yet still maintain compatibility.

takeda• 3 years ago

I wouldn't say that GIL will never be removed, but I believe the GIL cannot be removed without breaking a lot of existing code.

That means there could be another drama with migrations if that would be done.

I think the most likely way they can effectively eliminate GIL would be to provide a compile option that would basically say "this enables paralellization, but your code is bo longer allowed to do A, B, C (there probably would be a lot more things)"

People who want to get it would then adapt their code, and there could be pressure for other packages to make them work in that mode.

godelski• 3 years ago

Histortically, the main value of GIL removal proposals and implementations has been to spur the core team to speed up single core codes.

While I'm all for increasing single threaded performance[side rant] is this really a good argument? My understanding is that Moore's Law only currently exists because of the existence of more cores. Clock frequency has stagnated since 2004[0]. I mean feature size (Moore's Law) still exists[1] but IPS/core seems significantly flatter than IPS[2]. Aren't most of our performance gains from mutlicore? And as we push more in this direction (e.g. GPU taking over compute) doesn't this make this even worse for python? (Yes I understand that you can make C/CUDA calls but doesn't the GIL make problems here as well as prevent a native python solution?)

[side rant] Still frustrated by things like that difference in speeds between math.sqrt(2.) (~0.002s/10k), np.sqrt(2.) (~0.010/10k), torch.sqrt(torch.tensor([2.])) (~0.039/10k). I know there's more going on in capabilities, but it is of course frustrating by the large differences.

[0] http://cpudb.stanford.edu/visualize/clock_frequency

[1] http://cpudb.stanford.edu/visualize/technology_scaling

[2] https://en.wikipedia.org/wiki/Instructions_per_second#Millio...

zerkten2• 3 years ago

This feels like it's playing out as I expected. I followed Python, and the Python community, really closely from 2008-2016 when there were tons of relatively small scale experiments happening. This all happened organically to a large extent and there was no one coordinating a grand vision. It seems like we have a continuation of this giving rise to the concern that there is some battle.

I suspect there will be some butting of heads for a while before they work things out after seeing how the community reacts. All of this could be handled better with some thoughtful proactive engagement, but that's not really how things operate and there is no one to really enforce it.

jillesvangurp2• 3 years ago

The GIL has been a blocker for many years. It's nice that the team is making progress of course. IMHO it's one of those bandaids they need to rip off.

I was listening to the interview with Chris Lattner with Lex Friedman a week ago or so. Very interesting discussion on his project mojo which intends to build a new language that is backwards compatible and a drop in replacement for python with opt in strict typing, better support for native/primitive types where this makes sense, easier integrations with hardware optimizations, and of course no GIL. The idea would be that the migration path for existing code is that it should just work and then you optimize it and provide the compiler with type hints and other information so it can do a better job. Very ambitious roadmap and I'm curious to see if they'll be able to deliver.

The main goal seems to be to enable programmers to do the things you currently can't do in python because it's too slow in python without running into a brick wall in terms of performance.

I mostly work with JVM languages and a few other things but I occasionally do a bit with python as well. I've always liked it as a language but I'm by no means an expert in it. I recently spent a day building a simple geocoder and since I know about the GIL, I went straight for the multi processing library and did not bother with threads. IMHO there's absolutely no point in attempting to use threads with python with the GIL in place. I needed to geocode a few hundred thousand things in a reasonable time frame, so all I wanted to do was use a few different processes concurrently so I could cut down the runtime to something reasonable.

Python is ok for single threaded stuff but you run into a brickwall doing anything with multiple processes or threads and juggling state. In the end I just gave up and wrote a bunch of logic that splits the input into files, processes the files with separate processes, waits for that to finish, and then combines the output files. Just a lot of silly boiler plate and abusing the file system for sharing state. It does what it needs to but it feels a bit primitive and backwards and I'm not proud of the solution.

Removing the GIL, adding some structured concurrency, and maybe some other features, would make python a lot more capable for data processing. And since there are a lot of people already use python for that sort of thing, I don't think that would be such a bad thing. Data science and data processing are the core use case for python. I don't think people actually care a lot about the raw python performance. It's never been that great to begin with. If it's performance critical, it's mostly being done via native libraries already.

robertlagrant• 3 years ago

This is an interesting writeup. Could you go for asyncio.gather[0] or TaskTaskGroups[1] these days? Or would that not help?

[0] https://docs.python.org/3/library/asyncio-task.html#asyncio....

[1] https://docs.python.org/3/library/asyncio-task.html#asyncio....

nologic01• 3 years ago

Data science and data processing are the core use case for python

indeed. one would almost hope that all the different aspects of "performance" and "concurency", their memory, disk or network profile etc get their own dedicated labels. The conflation of these distinct dimensions is a major source of confusion (and thus a waste of bandwidth).

mixmastamyk3• 3 years ago

Is this io-bound or cpu-bound? Hard to tell from your one word description, “geocode”. Is that local or a network call?

If you’ve broken up the input already I’d use the shell to parallelize, ie for &. If network, async is probably what you want.

gpderetta6• 3 years ago

If the GIL were an optional interpreter parameter you could spawn GILed subinterpreters and GILless subinterpreters according to your needs.

dist-epoch• 3 years ago

As someone who observed Python core development for many years, a major change to the interpreter REQUIRES core-dev buy in. There have been at least 5 big projects which proposed large changes, they have all been declined.

It is a NIH syndrome, if a big project doesn't originate in the dev team, it will not be accepted.

btilly6• 3 years ago

My point of view is that anyone who wants to write multithreaded code, shouldn't be trusted to. Making it easier for people to justify this kind of footgun is a problem.

Also, no matter how much you wish it otherwise, retrofitting concurrency on an existing project guarantees that you'll wind up with subtle concurrency bugs. You might not encounter them often, and they're hard to spot, but they'll be there.

Furthermore existing libraries that expect to be single-threaded are now a potential source of concurrency bugs. And there is no particular reason to expect the authors of said libraries to have either the skills or interest to track those bugs down and fix them. Nor do I expect that multi-threaded enthusiasts who use those libraries in unwise ways will recognize the potential problems. Particularly not in a dynamic language like Python that doesn't have great tool support for tracking down such bugs in an automated way.

As a result if "no GIL" ever gets merged, I expect that the whole Python ecosystem will get much worse as well. But that's no skin off of my back - I've learned plenty of languages. I can simply learn one that hasn't (yet) made this category of mistake.

coldtea17• 3 years ago

My point of view is that anyone who wants to write multithreaded code, shouldn't be trusted to. Making it easier for people to justify this kind of footgun is a problem.

It's 2023 already. 1988 called.

samsquire3• 3 years ago

My deep interest is multithreaded code. For a software engineer working on business software, I'm not sure if they should be spending too much time debugging multithreaded bugs because they are operating at the wrong level of abstraction from my perspective for business operations.

I'm looking for an approach to writing concurrent code with parallelism that is elegant and easy to understand and hard to introduce bugs. This requires alternative programming approaches and in my perspective, alternative notations.

One such design uses monotonic state machines which can only move in one direction. I've designed a syntax and written a parser and very toy runtime for the notation.

https://github.com/samsquire/ideas5#56-stateful-circle-progr...

https://github.com/samsquire/ideas4#558-state-machine-formul...

The idea is inspired by LMAX Disruptor and queuing systems.

iskander• 3 years ago

My point of view is that anyone who wants to write multithreaded code, shouldn't be trusted to. Making it easier for people to justify this kind of footgun is a problem.

Out of curiosity, have you done any Rust programming and used Rayon?

It's hard to convey how easy and impactful multi-threading can be if properly enclosed in a safe abstraction.

hklzr1002• 3 years ago

This is a good point. With tsan and helgrind multithreading becomes manageable in C/C++, nothing like that exists (or will exist) for Python.

coldtea17• 3 years ago

There is also the argument that it could "divide the community" as some C extensions may not be ported to the new ABI that the no GIL project will result in

I think the arguments are a red herring. It's more rationalizations for not wanting to do it.

samsquire3• 3 years ago

I have often wondered what the solution to the serialisation of objects between subinterpreters is.

If its garbage collection that's the problem, I think you could transfer ownership between threads, so the subinterpreter takes ownership of the object and all references to it in the source interpreter are voided.

Alternatively you can do something like Java and all objects are in a global object allocator, passing things between threads doesn't require interpretation, just a reference.

ptx5• 3 years ago

If we could just get efficient passing of objects graphs from one subinterpreter to another, which is not in the current plan, I think that would solve a lot of use cases. That would allow producer/consumer-style processing with multiple cores without the serialization overhead of the multiprocessing module.

Removing the GIL seems like it could make things more complicated in many ways by making lots of currently thread-safe code subtly unsafe, but I might be wrong about this. (...in which case it would just make things very slow because everything is synchronized?)

bastawhiz• 3 years ago

Their argument is that the "sub interpreters" they are adding (each with its own GIL) will fulfil the same use cases of multithreaded code without a GIL, but they still have the overhead of encoding and passing data in the same way you have to with sub processors.

This is smart, though, because (even if it's not great) there's a lot of evidence that it works in practice. Specifically, this is almost exactly what JavaScript does with workers. It's not a great API and it's cumbersome to write code for, but it got implemented successfully and people use it successfully (and it didn't slow down the whole web).

samwillis5• 3 years ago

This just posted on the Python forum is a brilliant rundown of the conflicting "Faster Python" and "No GIL" projects, and a proposal (plus call for funding) for a route forward.

I think everyone would agree that trying to combine both would be ideal!

"A fast, free threading Python"

https://discuss.python.org/t/a-fast-free-threading-python/27...

jrochkind13• 3 years ago

this is a good read and deserves to be on the homepage with it's own thread too!

dragonwriter3• 3 years ago

It is from the person most involved in the faster-with-GIL effort, and its recommendation is to prioritize that effort in any case, and if the resources are available for that and no-gil, do both.

Not that I disagree with the recommendation, but one of the sides saying “as long as resources make us choose, choose my side” is...not really surprising.

nmstoker• 3 years ago

I do hope the dialogue stays cordial, constructive and open rather than becoming distinct entrenched camps - the Python community has a strong and mature community spirit so this seems plausible and not too much wishful thinking.

Much as No GIL would be an adventure, I'm leaning towards the more gradual and stable changes from the FasterPython team and I can see that throwing No GIL into the mix adds complexity at an inopportune moment.

AlphaSite2• 3 years ago

Nogil would give far larger returns and I wish they’d focus on that. That’s the best way to a faster python.

JohnFen• 3 years ago

Oh, boy. Will any of that impact backward compatibility?

I don't develop anything in Python, but it is used by several applications of importance to me. The lack of compatibility between versions is a thing that bites me hard, and I tend to curse Python because of it.

hklzr1002• 3 years ago

Where is the progress? They claim "10-60%" improvements over Python 3.9 (I believe) and I don't notice much, partly because Python has always been sped up by C-extensions.

The price is an added complexity of the code base.

I truly don't understand why Python always gets a pass and people applaud every announcement, no matter how trivial or elusive it is.

The GIL effort is another matter. I'd rather have a simple interpreter with no-GIL than this mess of relatively small speedups.

But like other GvR efforts where he presided over a small group of people who did the work his efforts will of course go in. Like asyncio, the suboptimal "match" statement, the peg parser (which adds new workloads for other implementations because the de-facto DFL cannot be bothered with publishing an LALR grammar).

Python is a glue language, people can go elsewhere for speed.

geekraver• 3 years ago

It’s overstating the case to call this a “struggle” between factions; it’s an important discussion with a lot of ramifications (and while it is unresolved a lot of work is stalled).

https://discuss.python.org/t/a-fast-free-threading-python/27...

henrydark• 3 years ago

Looks cool. This caught my eye

C++ and Java developers expect to be able to run a program at full speed (or very close to it) under a debugger.

I haven't worked in Java too much, but in C++ I don't remember having this expectation

Chabsff• 3 years ago

Think of it more as: It's still possible, painful as it may sometimes be, to debug optimised C++ code running at full speed.

qsdf38100• 3 years ago

Well, yes, but it quickly gets as painful as debugging raw assembly with almost no symbol informations. You might get lucky from time to time and get some debug info available for some variables, but in hot loops and highly inlined code, you're back to raw assembly. Doable for sure, but 100x slower to figure out anything compared to non-optimized code.

mm007emko• 3 years ago

Java programs might not run in debugger very well either, depends on where and how you place breakpoints.

However I'd be glad if profilers (and notably memory profiler) would slow down a Python program only as much as valgrind does C.

The_Colonel• 3 years ago

I noticed that java with a connected debugger can be very fast even with breakpoints, but stepping over can be very slow. Which is a big weird, since "step over" is basically just putting the breakpoint on the next line.

gyrovagueGeist6• 3 years ago

Can someone give a good argument of why subinterpreters are an interesting or useful solution to concurrency in Python? It seems like all the drawbacks of multiprocessing (high memory use, slow serialized object copying) with little benefit and higher complexity for the user.

The nogil effort seems like such a better solution, that even if it breaks the C interface, subinterpreters aren't worth considering.

bratao2• 3 years ago

I understand that sub-interpreter can perform better on object copying as it is sharing the same memory. But yeah, nogil looks like the correct way.

samus2• 3 years ago

Easy interop with C is one of the core selling points of Python. It's not just about performance - it's about Python being able to be a glue language that can interface with any legacy or system library written in C or being accessible via FFI. A LOT of systems exist that take advantage of this, and changes to the C interface impact all of these. Unless the porting story is thought out extraordinary well, it would be another disaster like Python 2->3. Since this affects C code, it won't be anything but tricky.

gyrovagueGeist6• 3 years ago

From reading the nogil repo and related PEP, C ABI breaking does not seem to be the worst problem. An updated Cython, Swig, etc seems like it would be enough in most cases to get something running. More extreme cases might only have ~dozen LoC changes to replace the GIL Ensure/Release patterns.

The hidden really hard problem is that extension modules may have been written relying on GIL behavior for thread safety... these may be undocumented and unmaintained.

Even so I hope the community decides it is worth it. A glue language with actual MT support would be much more useful.

celeritascelery5• 3 years ago

Can someone give a good argument of why subinterpreters are an interesting or useful solution to concurrency in Python?

I will give it a shot.

Subinterpreters are better than multiple processes because:

- they have significantly less memory overhead

- they can move objects much faster between subinterpreters because they don’t need to serialize through a format like JSON

- since they are all in the same process you can implement things like atomics or channels easily.

Subinterpreter are better then no-Gil because:

- they make the code easier to reason about and debug relative to raw multi-theading

- they don’t negatively impact single threaded (basically all existing) python code performance

- they don’t require any changes to the C interface, preventing a fractured ecosystem

- they can’t have data races

Spivak3• 3 years ago

- they don’t negatively impact single threaded (basically all existing) python code performance

I think this deserves an extra callout because even your multi-threaded Python programs are effectively single threaded and benefiting from the performance gain.

spacechild12• 3 years ago

- they can move objects much faster between subinterpreters because they don’t need to serialize through a format like JSON

Why do you think that you would need to serialize to JSON? Pipes and sockets can deal with binary data just fine. With shared memory, there wouldn't be any difference at all.

- since they are all in the same process you can implement things like atomics or channels easily.

This is also possible with shared memory.

AFAICT the advantage of subinterpreters over subprocesses are:

- lower memory overhead

- faster creation/destruction time

- ability to share global data (with subprocesses the data would either need to be duplicated or live in shared memory)

sergiomattei• 3 years ago

they can’t have data races

How so? Asking out of curiosity.

ptx5• 3 years ago

they can move objects much faster between subinterpreters because they don’t need to serialize through a format like JSON

That would be a huge advantage, but it's not there yet. According to PEP 554 [1] the only mechanism for sharing data is sending bytes through OS pipes, which is exactly the same as for multiprocessing and requires the same sort of serialization.

[1] https://peps.python.org/pep-0554/#api-for-sharing-data

kmod2• 3 years ago

Couple corrections:

- They absolutely do have to serialize, usually via pickle. I'm pretty sure objects are not sharable between subinterpreters and there is not a plan for that. The main reason people think subinterpreters are good ("you can just share the memory!") is not actually true.

- They don't require any changes to the C interface because those changes were already made, and a fair amount of cost was paid by C library maintainers. So it's true, subinterpreters are at an advantage in this regard, but that's more of a political question than a technical one

nhumrich• 3 years ago

Sub interpreters are still faster than processes. With them you could do continuation message passing which other modern languages, such as go, use for multi-threading. Also, for cases such as web apps or data science training, you don't need to share memory between threads, and a sub interpreter uses a lot less resources than a full python process.

Even if it breaks the c interface

Than most of your python packages wouldn't work. A python that isn't backwards compatible? Ya, that has been tried once before, and was a disaster. If you want a non-backwards compatible gil-less python, it already exists. You can find versions of nogil online.

globular-toast3• 3 years ago

Minor nitpick: Python can perfectly well do concurrency. What you mean is parallel execution (multi-threading).

gyrovagueGeist6• 3 years ago

Point taken! Thanks, I always mess this up when talking colloquially.

bsder• 3 years ago

Pure uninformed speculation follows ...

I suspect sub-interpreters are a punt and a feint.

My guess is that there will likely be exactly 2 sub-interpreters in most Python code. One which talks to an old C API with a GIL and one which talks to a new C API without a GIL.

It's going to be a lot easier to manage handing objects between two Python sub-interpreters than to manage handing objects between two incompatible ABIs.

kzrdude9• 3 years ago

Here's the recent subinterpreters talk, it has information about it https://www.youtube.com/watch?v=3ywZjnjeAO4

phkahler• 3 years ago

From the pip on subinterpreters:

> In this case, multiple interpreter support provide a novel concurrency model focused on isolated threads of execution. Furthermore, they provide an opportunity for changes in CPython that will allow simultaneous use of multiple CPU cores (currently prevented by the GIL–see PEP 684).

This whole thing seems more like something developer wants to do (hey, it's novel!) than something users want. To the extent they do want it, removing the GIL is probably preferable IMHO. That a global lock is a sacred cow in 2023 seems strange to me.

Maybe I'm misunderstanding, but I don't want an API to manage interpreters any more than I want one for managing my CPU cores. Just get me unhindered threads ;-)

mkoubaa2• 3 years ago

Most typical application developers don't want, but that doesn't mean it doesn't have very specific important use cases. For example, an application might embed python in memory and need isolated contexts. Or an http server needs to have multiple threads of concurrent work with minimal overhead

jonnycomputer6• 3 years ago

I'm going to admit that what I really want to see is a strong push to standardize and fully incorporate package management and distribution into python's core. Despite the work done on it, it's still a mess as far as I can see, and there is no single source of truth (that I know of) on how to do it.

For that matter, pip can't even search for packages any more, and instead directs you to browse the pypi website in a browser. Whatever the technical reasons for that, its a user interface fail. Conda can do it!!!!! (as well as just about any package management system I've ever used)

asylteltine• 3 years ago

Python’s dependency management, or lack there of, its import system, and the lack of strong typing really make me hate it. It’s the first language I really felt adept with, but once I learned Go, I never looked back. Every time I have to use python it’s like coding with crayons.

Aperocky• 3 years ago

Premature optimization is root of all evil.

Python isn't perfect, and mostly unsuitable for any system where performance is in consideration.

That leaves everything else including personal utility scripts and packages I use each day to automate random stuff. And I hugely appreciate how fast and simple it is to develop in python, unlike certain languages that literally depends on IDEs due to the verbosity and unnecessary cognitive load.

pnt122• 3 years ago

I think type hints help a lot. A codebase with classes and type hints reads much better than one using ad-hoc dictionaries for every data structure.

But on the other hand I don't really like Go, so maybe it's different languages for different tastes.

wendyshu• 3 years ago

What aspect of python's type system do you find insufficient?

bandrami• 3 years ago

It's beyond "mess" well into "fiasco" and frankly I'm astounded people think there's a more important issue facing the language right now. Look, for an example of a high-prestige project, at Spleeter, which spends multiple pages of its wiki describing how to install it with Conda and then summarizes "Note: as of 2021 we no longer recommend using Conda to install Spleeter" and nothing else.

noitpmeder• 3 years ago

What are you smoking? The readme for spleeter clearly shows the two simple commands needed to install -- one being a conda install for system level dependencies and one being pip for the spleeter python package itself.

woodruffw12• 3 years ago

I'm going to admit that what I really want to see is a strong push to standardize and fully incorporate package management and distribution into python's core. Despite the work done on it, it's still a mess as far as I can see, and there is no single source of truth (that I know of) on how to do it.

Package management is standardized in a series of PEPs[1]. Some of those PEPs are living documents that have versions maintained under the PyPA packaging specifications[2].

The Python Packaging User Guide[3] is, for most things, the canonical reference for how to do package distribution in Python. It's also maintained by the PyPA.

(I happen to agree, even with all of this, that Python packaging is a bit of a mess. But it's a much better defined mess than it was even 5 years ago, and initiatives to bring packaging into the core need to address ~20 years of packaging debt.)

[1] https://peps.python.org/topic/packaging/

[2] https://packaging.python.org/en/latest/specifications/index....

[3] https://packaging.python.org/en/latest/flow/

jonnycomputer6• 3 years ago

which is why I said, "Despite the work done on it"

jshen11• 3 years ago

Is there anything in there about managing dependencies within a python project? What is the canonical way to do that in python today?

globular-toast3• 3 years ago

There it is. The obligatory comment on every Python thread on HN. It's most popular programming language in the world. Other people can figure it out, apparently.

woodruffw12• 3 years ago

I think we can be more charitable than this: it's possible to be both immensely popular and to have a sub-par packaging experience that users put up with. That's where Python is.

kzrdude9• 3 years ago

Packaging is a big topic right now, and a lot is happening - that includes a lot of good tool improvements. I think that's one reason for these comments, because it's close to top of mind

jonnycomputer6• 3 years ago

I love python. It is my go-to language for just about everything. But that also means that I feel the pain points pretty acutely. And you know what, I'm not alone.

jonnycomputer6• 3 years ago

Oh look: https://news.ycombinator.com/vote?id=36343991&how=up&auth=85...

aranke3• 3 years ago

I gave a talk about this at the Packaging Summit during Pycon which was well received, so the team is definitely aware of the problem.

However, the sense I got was that it was going to be a lot of work to “fix Python packaging” which wasn't feasible with an all-volunteer group.

At work, we're migrating away from pip as a distribution mechanism for this reason; I don't expect to see meaningful improvements to the developer experience anytime soon.

This is especially true because pip today is roughly where npm was in 2015, so there's a lot of fundamental infrastructure work (including security) that still needs to happen. An example of this is that PyPI just got the ability to namespace packages.

LordKeren• 3 years ago

we're migrating away from pip as a distribution mechanism for this reason

Could you elaborate on what you’re using as a replacement?

di2• 3 years ago

An example of this is that PyPI just got the ability to namespace packages.

You're thinking of organizations, which are not namespaces: https://blog.pypi.org/posts/2023-04-23-introducing-pypi-orga...

orbisvicis• 3 years ago

How multithreaded programs depend on the GIL rather than use proper locking? The No GIL project might break a lot of multithreaded apps.

gyrovagueGeist6• 3 years ago

It would require no changes from pure Python apps (as the nogil implementation preserves the current behavior & thread safety of python objects).

But any C extensions that rely on the GIL for thread safety would be an issue..

avidphantasm2• 3 years ago

They must've explored this, but couldn't one make a GIL emulator/wrapper for legacy extensions so that they can still work in GIL-less Python while they are (hopefully) updated to work with the new synchronization primitives?

cellularmitosis• 3 years ago

Experiments on the register machine machine are complete

This is a worthwhile watch on this topic: https://youtu.be/cMMAGIefZuM

kzrdude9• 3 years ago

faster-cpython team has done a lot of work to experiment on it: https://github.com/faster-cpython/ideas/issues/485#issuecomm...

I wonder if the plan written there is current.

tasubotadas• 3 years ago

PEP 669 – Low Impact Monitoring for CPython

Finally, 15 years later Python might also get something similar to VisualVM.

milliams• 3 years ago

Notably yesterday Guido posted an update on the Faster Python plans w.r.t. the no-GIL plans (https://discuss.python.org/t/pep-703-making-the-global-inter...) specifically:

  Our ultimate goal is to integrate a JIT into CPython

avidphantasm2• 3 years ago

Yeah, reading CPython 3.13 plans made it seem like they were backing their way into creating a JIT compiler.

samsquire3• 3 years ago

This is extremely exciting stuff. Thank you for Python and working on improving its performance.

I use Python threads for some IO heavy work with Popen and C and Java for my true multithreading work.

retskrad7• 3 years ago

Speaking of Python, as a beginner I have tried to grasp Classes and Objects and watched countless YouTube videos and Reddit/StackOverflow comments to understand them better but I'm just banging my head against the wall and it's not sticking. The whole __init__ method, the concept of self and why it's used, instance and class variables, arguments, all of it. When learning something, when you simply cannot grasp a concept however hard you try, what's the course of action? I have tried taking breaks but that's not helping.

switch0072• 3 years ago

Classes and objects exist in all object oriented program languages. Perhaps stepping back from Python and trying some more generic material might help?

retskrad7• 3 years ago

That's a good idea, I'll try that

harrelchris• 3 years ago

Either keep looking for explanations until it clicks, or try to break it down into more fundamental elements.

Classes and blueprints have a simple analogy that I'm sure you are familiar with.

Blueprints are instructions for how to build something, like a house. Once built, the house is a physical thing you can interact with. It has attributes, such as a height or color. It has things it can do or that can be done to it, like open a door or turn on some lights.

Classes are blueprints - they tell a computer how to build something. An object is what is built by the class - it has attributes and methods.

retskrad7• 3 years ago

Thanks, I appreciate it

ozzy6009• 3 years ago

I was the same way when I was a beginner, I didn't really "get" python classes until years later and using other programming languages. I recommend SICP if you want a more first principles understanding: https://web.mit.edu/6.001/6.037/sicp.pdf

retskrad7• 3 years ago

Thanks

Zizizizz• 3 years ago

Try out these Cory Schafer videos, I remember watching them 6 years ago and them being quite helpful. https://youtu.be/ZDa-Z5JzLYM

retskrad7• 3 years ago

Thanks

abecedarius2• 3 years ago

First, do you feel you understand OO in another language? So this is about how Python does it?

retskrad7• 3 years ago

I'm a beginner and Python is the only language I'm familiar with

kzrdude9• 3 years ago

I think working with it in practice is the only way forward. Looking up info, build something, work more, and let it become a feedback loop. People work long with systems before they "get" them.

Programming is not a "school" activity for me. It's a craft, you do stuff. That has eventually led to a depth of knowledge in various topics inside programming.

(Digression: With that said - we should think of a lot more "school" stuff as skills and crafts - stuff that you don't read to understand but you get better at with practice. A lot of maths class is skills, not knowledge.)

retskrad7• 3 years ago

Good advice, thanks

WoodenChair• 3 years ago

Build a project where you purposely use a bunch of your own custom classes. Learning by doing is best if the reading materials are not clicking.

montecarl• 3 years ago

Others have said something similar, but I will still chime in.

It sounds like you may want to feel like you have a complete understanding of classes, objects, and the way the work before you can begin working with them. This can almost never work. I haven't come across a topic where just reading about the topic is sufficient to fully understand it or even become proficient in it.

In my experience this is true for cooking, lab techniques in chemistry, electronics, and programming. Even when I have read something and felt that I understood it completely, as soon as I begin the activity I immediately realize that I had a fundamental misunderstanding of what I had read. That my brain had made some oversimplification or skipped passed some details so that I felt like I grasped the concept.

So if I had to describe the way I learn a new concept it would look like this:

1. Read many different descriptions/watch many different videos of the topic to get used to the terms and concepts

2. Try to apply those concepts in real life (write software, build a circuit, cook a meal)

3. Figure out where my understanding fell short, and go back to step 1

You want to make this loop as tight as possible. When you become expert at something you can do this activity super fast. When you first start out you may have to do quite a bit of reading to even have the baseline needed to attempt a concrete task. However, it is important to get started towards a real goal as soon as possible or you will be wasting your time feeling like you are learning and moving towards you goal, but you are not.

mixmastamyk3• 3 years ago

Go to school, with a good teacher. Yt videos are not a substitute for a proper course.

IshKebab• 3 years ago

I disagree on the school part. There are so many good resources available especially for Python programming. There's no way you need to pay for lessons. I don't think the kind of people you get teaching Python will be the most knowledgeable anyway.

But I would maybe recommend a good book if you're struggling.

njharman• 3 years ago

When learning something, when you simply cannot grasp a concept however hard you try, what's the course of action?

Learn by doing, don't learn by studying.

Pick a (hopefully real) problem, solve it using classes. Repeat. Continue repeating. You will either learn what OO is good for, what it is not good for and how you can use it to write better code. Or, learn that programming is not something you can grok.

If you don't have a "real" problem; Then write program to play tic-tac-toe; manage the and display board, take player inputs, detect when game is done (winner or draw).

Then expand it to 8x8 board, then to 3 players. Those changes should be easy with good OO design (lots rewrites, code changes). And probably "harder" with bad OO or no OO design.

btw this is 2nd interview question I and my team used for years.

IAmGraydon• 3 years ago

As everyone else said, use it. Don't try to understand by reading. Understand by doing.

_dain_• 3 years ago

Have you read this? It's one of the few I've come across that has the appropriate degree of empathy for the confused newcomer + actionable advice:

https://death.andgravity.com/same-arguments

And it doesn't fall into the "Dog inherits from Animal" taxonomic crap.

Alifatisk• 3 years ago

Ruby team approached parallelism & multicore in a cool way, they introduced the concept of the Actor model (like Erlang)!

bkovacev• 3 years ago

How would this (or any of the recent changes) affect popular web frameworks like Django / Flask / FastAPI? Would this increase performance in serialization or speed in general?

mkoubaa2• 3 years ago

Subinterpreters could make parallelism better for independent http server queries

pmoriarty• 3 years ago

Wish python would sort out their packages mess and let there be one and only one (obvious) way to do it.

kortex9• 3 years ago

Every single HN thread on python performance, ever:

Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove it?

That just is doing an incredible amount of heavy lifting. It'd be like saying, "Why doesn't the USA just switch entirely to the metric system?" It's a huge ask, and after being burned by the 2/3 transition, the python team is loathe to rock to boat too much again.

The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice.

Whatever your monday-morning quarterback idea on how to pull out the GIL is, I can almost guarantee, someone has thought about it, probably implemented it, and determined it will have one or more side effects:

- Reduced single-thread performance

- Breaking ABI/FFI compatibility

- Not breaking ABI immediately, but massively introducing the risk of hard to track concurrency bugs that didn't exist before, because GIL

- Creating a maintenance nightmare by adding tons of complexity, switches, conditionals, etc to the codebase

The team has already decided those tradeoffs are not really justifiable.

The GILectomy project has probably come the closest, but it impacts single-thread performance by introducing a mutex (there are some reference type tricks [1] to mitigate the hit, but it still hurts run time 10-50%), and necessitates any extension libraries update their code in a strongly API-breaking way.

It's possible that over time, there are improvements which simultaneously improve performance or maintainability, while also lessening the pain of a future GILectomy, e.g. anything which reduces the reliance on checking reference counts.

[1] PEP 683 is probably a prerequisite for any future GILectomy attempts, which looks like it has been accepted, which is great https://peps.python.org/pep-0683/

arp242• 3 years ago

There were already patches to "just" remove the GIL for Python 2.0 or thereabouts, over 20 years ago. Strictly technically speaking it's not even that hard, but as you mentioned it comes with all sorts of trade-offs.

Today Python is one of the world's most popular programming language, if not the most popular language. The GIL is limiting and a trade-off in itself of course – designing any programming language is an exercise in trade-offs. But clearly Python has gotten quite far with the set of trade-offs it has chosen: you need to be careful to "just" radically change the set of trade-offs that have proven themselves to be quite successful.

aldanor• 3 years ago

To think about it, perhaps US should have started metrification back in 1980 when EU enforced it for its members. It takes time, but is doable - if took Ireland 25 years to fully switch to metric.

The cost of switching increases over time and will increase further and further, making it less and less likely. Would have been way cheaper back then.

dragonwriter3• 3 years ago

To think about it, perhaps US should have started metrification back in 1980

The US started that in either 1875 or 1893, though, and somewhat more aggressively in 1975.

It reversed course in the 1980s, it didn't fail to start before that.

Groxx3• 3 years ago

Removing the GIL will also make some currently-correct threaded code into incorrect code, since the GIL gives some convenient default safety that I keep seeing people accidentally rely on without knowing it exists.

Unavoidable performance costs and reduced safety equals massive friction no matter how it's approached. It's not a question of "are we smart enough to make this better in every way", since the answer is "no, and nobody can be, because it can't be done". It's only "will we make this divisive change".

soulbadguy7• 3 years ago

That just is doing an incredible amount of heavy lifting. It'd be like saying, "Why doesn't the USA just switch entirely to the metric system?" It's a huge ask, and after being burned by the 2/3 transition, the python team is loathe to rock to boat too much again.
The GIL is deep, arguably one of the deepest abstractions in the codebase, up there with PyObject itself. Think about having to redefine the String implementation of a codebase in your language of choice.

I am somewhat familiar with the cpython code base, and talk to some folks involves in some of thousand new python runtime.

The problem is not that deep, and cpython is not that much different from other projects : the GIL is an implementation details that leaked through the API and now we have a bunch of people are relying on it. The question is what do we do about it. The trade-off in such situation are well known and just a question to pick the right one.

The team has already decided those tradeoffs are not really justifiable.

That's from my view the crust of the issue, the TLDR is that GIL-less python is not a priority for the python team, so they view any trade-off/comprise as "not justifiable". Especially something when it come to added complexity to the code base or what not...

Person with limited to zero experience with CPython internals> I hate the GIL, why don't they just remove it?

People have this reaction because having a single-threaded interpreter in 2023 is just ... embarrassing, what ever the reasons behind it.

nunuvit8• 3 years ago

It only takes a couple of minutes to educate yourself on this topic. After reading it, let me know if you still think they don't want to compromise.

https://www.artima.com/weblogs/viewpost.jsp?thread=214235

kortex9• 3 years ago

The problem is not that deep

Technically yes, the data structure can be abstracted over and removed, in that sense, it isn't "deep". But the reason I say it's deep is because of the deep implications and assumptions of the GIL being there. For decades, the codebase (and extensions) has grown with the expectation that the GIL enforces a certain behavior.

That's from my view the crust of the issue, the TLDR is that GIL-less python is not a priority for the python team, so they view any trade-off/comprise as "not justifiable". Especially something when it come to added complexity to the code base or what not...

Precisely. Because it's such a hard problem. If someone had a proposal to actually remove the GIL, limit the single core performance hit to say <10%, and not break extensions, I have no doubt the steering team would go for it. It would be huge PR for python, simply because of the Gil's bad rap.

Turns out that multi-interpreters give you most of the benefit of multithreading with nowhere near as much complexity.

People have this reaction because having a single-threaded interpreter in 2023 is just ... embarrassing, what ever the reasons behind it.

What other dynamic languages invented over 3 decade ago have natively multithreaded interpreters? Oh javascript, the (fundamentally simpler on a technical level and uses different gc techniques) language which has gotten millions of dollars in development by the biggest tech companies because it runs on nearly every browser and thus has huge incentives to optimize? If python ran in every browser, the Gil would be gone by now.

Java? Again, huge amount of backing, 15 years older than python.

Perl, ruby, lua, all use refcount and have single-threaded interpreters. Objective C might fit the bill for multithreaded refcount gc (I don't know, I'm asking gpt). Nim does, but it's rather modern, (2008). Swift is statically typed, which helps, and much newer (2014).

I guess that leaves Erlang, which again uses different gc techniques.

I guess the takeaway is refcount is probably not the best design choice for writing a modern dynamic language if you value multithreading.

kmod2• 3 years ago

You should check out the new nogil project by Sam Gross, which is what's being talked about these days -- he actually successfully removed the gil, but yes with the tradeoffs that you mention. The other projects were, by comparison, "attempts" to remove the gil, and didn't address core issues such as ownership races (which are far harder than making refcount operations atomic).

kortex9• 3 years ago

I indirectly referenced it. IIRC the main problems with his approach are the ABI problem and the mutex overhead. He tries to "solve" the performance hit by offsetting with performance gains elsewhere, but that raises the question "why not take the gains by themselves".

titzer• 3 years ago

Building a whole new interpreter and accompanying compiler tiers is a lot of work, still in 2023. Many different projects have tried to make this easier, provide reusable components, to offer toolkits, or another VM to build on top of. But it seems that none of these really apply, we're still at the "every language implementation is a special snowflake" territory. That's partly the case in Python just because the codebase has accumulated, rather nucleated, around a core C interpreter from 30 years ago.

IMHO the Python community has intentionally torpedoed all competing implementations of Python besides CPython to its own detriment. They seem to constantly make the task of making a compatible VM harder and harder, on purpose. The task they face now is basically building a new, sophisticated VM inside a very much non-sophisticated VM with a ton of legacy baggage. A massive task.

PeterStuer• 3 years ago

Just one question: Do you realy want Python to be held back by the GIL 10 years from now? If not, when do you want to start the change? If so, what do you think a CPU will look like in 10 years, and how would a GIL Python facilitate getting value from it?

kzrdude9• 3 years ago

You don't want python to still be reeling from grueling the gil ecosystem split, 10 years from now.

dboreham• 3 years ago

Just add some PR spin like JS did and declare the GIL a feature.

voxelghost• 3 years ago

Well, if we want to be charitable;

- The GIL is a feature that adds value, and was added for a reason. (As explained elsewhere in discussion)

And, if we want to be a bit less charitable about it;

- The GIL is a feature, in much the same way training-wheels on your bike is a feature. :-)

kzrdude9• 3 years ago

Some people need a three-wheeled motorcycle and for them a two-wheeled one is not an "upgrade". So yes, clearly different tools for different tasks.

RandyRanderson• 3 years ago

Many projects start out in Python b/c often new libs are python-first. Many of those run into performance issues and eventually determine that Python will never be fast b/c of the GIL.

I think it's very magnanimous of the python team, by not removing the GIL, to give Go, Java and C++ a chance.

fb03• 3 years ago

I'm actually rooting for RustPython to reach a level of maturity that we'd just be able to ship apis and stuff with it.... https://github.com/RustPython/RustPython

redsaber• 3 years ago

question: If RustPython did indeed reach maturity, are we going to need to choose which python interpreter to install on PC? or like on certain python version we will switch to the new interpreter?

kzrdude9• 3 years ago

CPython developers are still the leaders and those controlling the important Python infrastructure. You have to ask them. It's quite likely RustPython has no influence whatsoever on the question, and also quite likely that CPython is not going to ever throw out its existing work in favour of a different implementation.

FWIW, parallel implementations already exist, and maybe RustPython can join them.

fwungy• 3 years ago

The beauty of the GIL was that it made writing good python libraries easy, from the utility perspective. Python is such an amazing multi-tool because of its rich library.

Personally I'd like to see Python continue as the amazing multitool that it is has always been.

Go is the natural concurrency sibling for Python. High performance parts of Python applications should be linked to Go binaries, or simply be written entirely in Go.

Ideally Go linkage would be highly integrated into Python. There is a huge place in the world for GIL constrained Python. Enabling Python to push further into high performance environments is just going to make a problem worse.

Our Plan for Python 3.13

Related Stories