Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's up, Python? The GIL removed, a new compiler, optparse deprecated

bitecode.dev

Post reply on HN
Print view View original

231–240 of 302 posts

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#231

Post by FartyMcFarter »

crabbone wrote: post #220
masklinn wrote: post #8

Earlier quoted context omitted.

> Maybe for somewhat obscure multithreading cases. They're only "somewhat obscure" because currently you can't do it at all, so you don't do it and you do something else: it's of value for any case where you're multithreading for computational parallelism (as opposed to IO concurrency). The PEP also outlines a bunch of other situations where using process-based parallelism is problematic: https://peps.python.org/pep-…

> currently you can't do it at all Is not true. First of all, Python threads are mapped to OS threads. So, you can do "something". Now, in CPython C API there are tools for releasing and acquiring the global lock. They aren't complicated, and I used them in my own extensions. Not sure how popular across other extensions is this practice, but, at least some do use it. Some Python native functions release and acquire t…

> So, you can do "something".

You can only do "something" if that doesn't involve interpreting actual Python code. Which is a pretty big deal since we're talking about Python programming.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#232

Post by BiteCode_dev »

School-Cotton wrote: post #226
BiteCode_dev wrote: post #198

Earlier quoted context omitted.

Yes. I tried to come up with something that would convey in a few words that the GIL was going to be removed for sure this time. But as a Frenchmen, I couldn't find better. "GIL will be removed" was the closest, but it's very long, and it sounds like all those times we had the promise it would be, but it never did. So the Prophetic perfect tense is the best compromise: it asserts near certainty, it's short, and worst…

> the Prophetic perfect tense That is not really a thing in normal English. I had to look up what it even means, and it apparently exists only in the translation of a few passages of Biblical Hebrew (and now, apparently, the title of your post).

I guess I always felt like the chosen one deep down.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#233

Post by gjulianm »

rightbyte wrote: post #207
wodenokoto wrote: post #140

When it was an in dev project, I felt the consensus on HN was that it was amazing work and a shame that it looked like the steering committee wouldn’t adopt it. Now they have and everyone seems to hate it.

It is probably language design enthusiasts push all these backwards incompatibilities into Python because they are not the users of the language. They are a different group from those having their code broken in a never ending incompatibility churn. Well atleast it gives us jobs ...

I'm one of those happy to see the GIL removed. I've had troubles with the 2->3 transition and more recently with the 3.6 EOL, which wasn't as traumatic but still a little bit troublesome. Despite that, I prefer another transition and being able to actually use parallelism in Python rather than rewriting a huge codebase in a different language, and losing the advantages of Python.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#234

Post by BiteCode_dev »

antupis wrote: post #176
BiteCode_dev wrote: post #169

Earlier quoted context omitted.

It's the eternal pendulum: - take no risk, and people will blame the project for being static. - take risks, and people will blame the project for being reckless. E.G: - don't adopt a new feature, and your language is old, becoming irrelevant, and a wave of comments will tell you how they just can't use it for X because they don't have it. - break compat, and you will have a horde stating you don't care about users t…

World would need one more language which would have very barebone core something like very minimal go or python but strong metaprogramming features so you could expand language if you need.

It wouldn't stay barebone, or would stop being used. That's the point.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#235

Post by sanderjd »

xmaayy wrote: post #228
iknownothow wrote: post #171

Earlier quoted context omitted.

I would consider the following optimizations first before attempting to rewrite an HTTP API since you already did the hard part: 1. For multiples processes use `gunicorn` [1]. Runs your app across multiple processes without you having to touch your code much. It's the same as having the n instances of the same backend app where n being the number of CPU cores you're willing to throw at it. One backend process per cor…

> 1. For multiples processes use `gunicorn` This will load up multiple processes like you say. OP loads a large dataset and gUnicorn would copy that dataset in each process. I have never figured out shared memory with gUnicorn.

One way to achieve similar performance is redis or memcached running on the same node. It really depends on the workload too. If it is lookups by key without much post-processing, that architecture will probably work well. If it's a lot of scanning, or a lot of post-processing, in-process caching might be the way to go, maybe with some kind of request affinity so that the cache isn't duplicated across each process.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#236

Post by gjulianm »

crabbone wrote: post #215
doctoboggan wrote: post #31

Earlier quoted context omitted.

The big and obvious difference is that all the GIL vs no-GIL stuff happens in the background and your average python dev can just ignore it if they want to. The interpreter will note if you have C extensions that don't opt in to no-GIL and then will give you the GIL version. This is _very_ different to the 2-to-3 transition where absolutely every single person, even those who couldn't care less, had to change their c…

> your average python dev can just ignore it if they want to. Oh, so naive... All the mutation code in Python which "worked" because Python didn't really have any real concurrency. Add to it -- there's no real plan about what to do with Python concurrency. Removing GIL is only one "half" of the problem, you need to give developers some sort of a framework to use to deal with concurrency. Python's threads are extremel…

Which code is automatically going to run in threads? As you say, basically nobody uses Python threads. So even enabling no-gil, nothing is going to change because sequential code will still be sequential.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#237

Post by sanderjd »

aragilar wrote: post #230
mort96 wrote: post #194

Earlier quoted context omitted.

I want to warn people against multiprocessing in python though. If you're thinking about parallelizing your Python process, chances are your Python code is CPU-bound. That's when you should stop and think, is Python really the right tool for this job? From experience, translating a Python program into C++ or Rust often gives a speed-up of around 100x, without introducing threads. Go probably has a similar level of sp…

The first thing you should do is profile the code (py-spy is my preferred option) and see if there are any obvious hotspots. Then I'd actually look at the code, and understand what the structure is. For example, are you making lots of unnecessary copies of data? Are you recomputing something expensive you can store (functools.cache is one line and can make things much faster at the cost of memory)? Once you've done t…

Is there a better resource than the py-spy docs for figuring out how to use it?

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#238

Post by gjulianm »

quickthrower2 wrote: post #145
doctoboggan wrote: post #31

Earlier quoted context omitted.

The big and obvious difference is that all the GIL vs no-GIL stuff happens in the background and your average python dev can just ignore it if they want to. The interpreter will note if you have C extensions that don't opt in to no-GIL and then will give you the GIL version. This is _very_ different to the 2-to-3 transition where absolutely every single person, even those who couldn't care less, had to change their c…

But you need to pick your horse. In 5 years time, Python will either be GIL or no GIL, and it is hard to tell which. It might be a setting (which might be more ideal). If you assume nogil, you need to choose dependencies that support that. You may need to trade off: eschew dependencies that aren't looking like they will be nogil compatible by the deadline. You are stuck on Python 3.18 maintenance branch or whatever,…

You're missing something, which is that a lot of libraries will be "i-don't-care-about-gil". Only native extensions need to choose GIL or noGIL due to the ABI difference, but pure Python libraries should run with the same code in both variants. And a lot of them will probably be thread safe at some level (function or class) without any changes. For those that aren't thread-safe, I bet that quite a lot can just get away with a "NOT THREAD SAFE" warning and letting the user wrap access to them with locks.

And that's talking about multithreaded code. I bet that even with noGIL, lots of Python code will still continue to be single-threaded, making the gil/no-gil decision irrelevant (save for those native extensions).

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#239

Post by gjulianm »

quickthrower2 wrote: post #151
doctoboggan wrote: post #148

Earlier quoted context omitted.

I don’t really understand this. Unless I am missing something you should always pick the “no GIL” version as that will work with or without a GIL. Thread safe No GIL code would be totally fine to run on python compiled with the GIL with zero modifications. Because of this I don’t expect there to be multiple versions of any library. Once a library does the (admittedly heavy) lift to no GIL it will just be the main ver…

Each library maintainer (probably mostly volunteers) has to decide whether to put effort into making their code thread safe. Clearly it won't be 100% of libraries that "upgrade". Then on top of that, they know their effort might be for nothing if the decision is made to keep Python GIL-only all along (one of the possible 3 outcomes at the end of the 5 years: ["gil", "nogil", "both supported").

But thread-unsafe code is not the same as incompatible code. That's the point. You can just choose to say "NOT THREAD SAFE" (just as many C libraries aren't thread safe and need to be wrapped in locks to be used by multiple threads) and users will still be able to use it. More importantly, if it's a pure Python extension, you can just not modify the library and the users will still be able to use it whether or not they have gil or no-gil.

Re: What's up, Python? The GIL removed, a new compiler, optparse deprecated

#240

Post by nesarkvechnep »

wmwmwm wrote: post #14

Historically I’ve written several services that load up some big datastructure (10s or 100s of GB), then expose an HTTP API on top of it. Every time I’ve done a quick implementation in Python of a service that then became popular (within a firm, so 100s or 1000s of clients) I’ve often ended up having to rewrite in Java so I can throw more threads at servicing the requests (often CPU heavy). I may have missed somethin…

If your data doesn't change, you can leverage HTTP caching and lift a huge burden off of your service.
Post reply on HN