36 ms·

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

400 points by BiteCode_dev 3y ago

wiz21c 3y ago
Is LPython comparable to Nuitka ?
- dagw 3y ago
  It seems to be closer to pythran than Nuitka. Mainly in that Lpython only supports a subset of python and focuses on performance of numeric code. Nuitka focuses primarily on being able to compile all of python, and has performance only as a secondary goal.
wiz21c 3y ago
For the record, I have found that on LPython's homepage, there is a pretty complete list of all "compilers" for Python. Really interesting list.
dang 3y ago
Recent and related: Intent to approve PEP 703: making the GIL optional - https://news.ycombinator.com/item?id=36913328 https://news.ycombinator.com/item?id=36913328 - July 2023 (488 comments)
nico_h 3y ago
The tenses in the headline and the article are very iffy. It’s more like there will be work to remove the GIL that will start after a particular PEP will be approved. The main reason we are still writing some stuff in java at our shop is because parallel processing sucks with multiprocessing, and trivial in java. I look forward to a future where it as trivial in or even simpler in python.
crabbone 3y ago
Every release brings Python closer to becoming Java. Another ten or so years, and we'll have feature parity with Java 8 or something. Maybe it will even be as fast!
- ptx 3y ago
  And conversely every release of Java brings it closer to becoming Python. With Java 4 we got regular expressions. With Java 5 we got varargs, string formatting, boxed numbers, syntax for looping over collections and imports of static methods. With Java 7 we got Timsort, the sorting algorithm from Python. With Java 8 we got first-class functions. With Java 9 we got a REPL. With Java 11 we got implicit compilation of source files so you can run them directly. In more recent releases, we have previews of features corresponding to f-strings and ctypes.
  - crabbone 3y ago
    Don't get me wrong. I think Java and Python are both awful. I also think that by trying to exchange features they become even worse. I'm absolutely not excited and not looking forward to seeing any more versions of either of these languages. Well, maybe just a little bit, in an accelerationist kind of way.
deleted 3y ago
[deleted]
BiteCode_dev 3y ago
Summary: - Python without the GIL, for good - LPython: a new Python Compiler - Pydantic 2 is getting usable - PEP 387 defines "Soft Deprecation", getopt and optparse soft deprecated - Cython 3.0 released with better pure Python support - PEP 722 – Dependency specification for single-file scripts - Python VSCode support gets faster - Paint in the terminal
- swyx 3y ago
  great recap thanks!
  - thiht 3y ago
    It's literally the summary at the top of the article Doesn't anyone click on links anymore?
    - swyx 3y ago
      just trying to compliment the author on a useful blogpost, calm down.
      - thiht 3y ago
        Oh I didn’t realize it was the author of the blogpost that also posted this summary. I thought someone copy pasted it because « it saves a click », as it sometimes happen!
        BiteCode_dev 3y ago
        I started to write summaries for all articles everywhere I post. No need for people to waste their time if they are not interested in the topic. This also keeps my traffic stats clean: people that comes are the ones that are interested in the content. The number are smaller, but closer to what my real readership looks like. Since I have no ads, I don't aim for volume, so I rather know the truth.
andrewstuart 3y ago
From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is that right?
- FartyMcFarter 3y ago
  I would disagree with that. The GIL means you can't use Python multithreading in order to take advantage of more CPU time by parallelism. Obviously getting rid of the GIL makes that a real option, just as it is in other languages.
- squeaky-clean 3y ago
  Currently, yes that's kind of true. But it's really only considered obscure because the GIL makes it so you either have to do some weird non thread pattern or go with a different language, and people often go with a different language. Kind of a Catch-22 of "Well no one uses it that way, so why should we make it possible to use it that way? Well, no one uses it that way because it's impossible to use it that way"
- kukkamario 3y ago
  Well Python doesn't really do proper multi-threading currently thanks to GIL blocking any additional execution threads. So removing it would enable making Python code that is actually multi-threaded without resorting to extra processes and their overhead. So if you are writing small single process Python script then removing GIL shouldn't really change much. If you are doing some heavier computing or eg. running server back-end, then there are significant performance gains available with this change.
  - School-Cotton 3y ago
    You don’t have to use separate processes to get the benefit of multithreading in Python today — you can also call into a library written in native code that drops the GIL (e.g. Numpy or Pytorch).
    - 3y ago
fbdab103 3y ago
Still not encouraged by the no-GIL, "We don't want another Python 2->3 situation", yet very little proffered on how to avoid that scenario. More documentation on writing thread-safe code, suggested tooling to lint for race conditions (for whatever it is worth), discussions with popular C libraries, dedicated support channels for top tier packages, what about the enormous long-tail of abandoned extensions which still work today, etc.
- thiht 3y ago
  > Note that if the program imports one single C-extension that uses the GIL on the no-GIL build, it's designed to switch back to the GIL automatically. So this is not a 2=>3 situation where non-compatible code breaks. Sounds good enough to me, am I missing something?
- LexiMax 3y ago
  In a past life I hacked on PHP for a living, and in the time it took Python 2 to ride off into the sunset, PHP got two major migrations under its belt in 5.2 to 5.3, and then again 5.6 to 7.0. It was amazing to see the contrast between the two languages. PHP gave you plenty of reasons to upgrade, and the amount of incompatible breaking changes was kept to a minimum, often paired with a way to easily shim older code to continue working. I really hope to see no-GIL make it into Python, but in the back of my mind I also worry about what lessons were learned from the 2 to 3 transition. Does the Python team have a more effective plan this time around?
  - charrondev 3y ago
    I’ve taken an application codebase from PHP 5.3 to 8.2 now and it was relatively easy the whole way. The real key to minimize the pain was writing effective integration tests with high coverage. We didn’t have a good test suite to start but once we added some utilities to easily call our various endpoints (and internal API client if you will) and make assertions about the coverage came quickly. Popular frameworks like Laravel offer such test utilities out of the box now. That combined with static analysis tools like psalm make it so we can fearlessly move past major upgrades. One thing I was surprised at was just how much crap PHP allowed with just a notice (not even a warning for a long time). A lot of that stuff still works (although over time some notices have progressed to warnings or errors gradually). We have our test suite convert any notices or warnings to exceptions and fail the test case.
devwastaken 3y ago
This is exactly what I have been looking forward to. Allow me to do no-gil, let me the developer make that choice. There are issues with that certainly, but I am conscious of this fact and given an analysis of no-gil benefits it is significantly more beneficial to have no-gil for certain use cases. One of the most significant of these cases to me is threading outside an Operating system context. What if I want to use both of the cores to a Cortex M0? Multiprocessing can't help me, there are no processes. If I need locking, I will impliment it using the platform I have available to me. The second is the fact that CPU's are increasingly scaling in core count. When I have to use multiprocessing the program becomes far more complex than one would expect. Why am I doing message passing and shared memory when the OS and CPU supplies better tools already? It also pollutes the process ID's. Imagine if we built every application in Python - there would be hundreds of thousands of individual processes all to use multiple cores. Because this is a problem mostly unique to python we often end up having to build applications in other languages that otherwise would have been better in Python. I want a world where I can say "just use python" to almost anything. Telling new coders to drop their favorite language and use any other language to get the result they want immedietely kills the innovation they are working on. Instead of spending time creating the idea, they're spending time learning a languages I believe are unnecessary.
- ActorNightly 3y ago
  > let me the developer make that choice. The final push towards making no-GIL as the only option is the big issue here. An optional no-GIL is ok (although a waste of time), making it default is bad. >What if I want to use both of the cores to a Cortex M0 The solution to anything performant in Python is writing the C extension, just like Numpy did. Python isn't meant to be a performant language. The GIL allows you to write code without thinking about complexities of parallelism.
wmwmwm 3y ago
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 something but I couldn’t figure out how to get the multi-threaded performance out of Python but of course no-GIL looks interesting for this!
- SanderNL 3y ago
  It sounds I/O heavy, but you mention it being CPU-heavy in which case I’d say Python is just not the right tool for the job although you may be able to cope with multiprocessing.
- iknownothow 3y ago
  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 core, full isolation. 2. For multiple threads use `gunicorn` + `gevent` workers [2]. Provides multiprocessing + multithreaded functionality out of the box if you have IO intensive. It's not perfect but works very well in some situations. 3. Lastly, if CPU is where you have a bottleneck, that means you have some memory to spare (even if it's not much). Throw some LRU cache or cachetools [3] over functions that return the same result or functions that do expensive I/O. [1]: https://www.joelsleppy.com/blog/gunicorn-sync-workers/ https://www.joelsleppy.com/blog/gunicorn-sync-workers/ [2]: https://www.joelsleppy.com/blog/gunicorn-async-workers-with-gevent/ https://www.joelsleppy.com/blog/gunicorn-async-workers-with-... [3]: https://pypi.org/project/cachetools/ https://pypi.org/project/cachetools/
  - xmaayy 3y ago
    > 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.
hanniabu 3y ago
Will writing multithreaded code become easier? Or will the developer UX remain the same?
- dpedu 3y ago
  The opposite, writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself that the GIL previously avoided. But, the tradeoff is that multithreaded programs could now actually achieve multithreaded performance gains.
  - bvrmn 3y ago
    A single Go thread still replaces 10 Python threads, speaking very roughly. It's a quite particular narrow set of problems noGIL would solve.
    - sapiogram 3y ago
      Looks like ML workloads is the primary use case here, no amount of goroutines will help you there as long as the ecosystem doesn't exist.
  - Jtsummers 3y ago
    > writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself I'd phrase this differently: Writing correct multithreaded code will be just as challenging (or not, depending on the person and their comfort with concurrent and parallel code development) as before, but now you won't be able to get away with sloppy multithreaded code that relied on the GIL to not break.
    - fbdab103 3y ago
      It was correctly written to the invariant promises of the platform at the time. If Python is altering the deal, that does not suddenly make the library writer at fault.
bigbillheck 3y ago
Python's been a little too happy to hard-deprecate things for my liking, so this soft-deprecation sounds pretty good.
mkoubaa 3y ago
And alternative C APIs are being proposed, which is as exciting as all of the above
cvnmalk 3y ago
Which, except for optparse, was all on the front page yesterday. So optparse is deprecated. More work I guess apart from auditing extensions for threading. Life is great in the Python treadmill.
- maxnoe 3y ago
  IIRC, optparse was going to be be removed in 3.5(?) but outcry was large . It has a depreciation warning in the docs since 3.2. It was in the "please just use argparse instead" state for a long time, this "just" adds an actual code warning.
- nickcw 3y ago
  I've tried to love argparse but it is so complicated. I always have to read the docs each time I use it. getopt has its own brutal simplicity.
  - moonshinefe 3y ago
    If you aren't averse to using a third party package, on my personal projects I always found https://github.com/docopt/docopt https://github.com/docopt/docopt to be nice. You can kill 2 birds with one stone by documenting your scripts while also providing the argument structure / parsing.
  - kzrdude 3y ago
    I think argparse works fine. What worries me is that it's also "soft-deprecated", because devs have said it should get no further development. I hope it stays around, because I use it by default as a no-dependencies solution that I know how it works.
    - mardifoufs 3y ago
      Wait.. source? If argparse isn't getting more development, what's the current alternative?
      - deleted 3y ago
schemescape 3y ago
The title says "GIL removed", but the article says "This means in the coming years, Python will have its GIL removed." I'm assuming the article is correct and the GIL has not been removed yet (but there is a plan to remove it in the future). If that's not the case, please correct me!
- BiteCode_dev 3y ago
  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 case scenario the article remove ambiguity. Plus the news popped up this week in HN front page, so a lot of people knew the context.
  - School-Cotton 3y ago
    > 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).
    - BiteCode_dev 3y ago
      I guess I always felt like the chosen one deep down.
- kzrdude 3y ago
  There's been an announcement that they are probably going to decide to start a development plan that can eventually lead to removing the GIL later, if it works out. That plan is called PEP 703 and this is the factual basis: "We intend to accept PEP 703, although we’re still working on the acceptance details."
- Jtsummers 3y ago
codedokode 3y ago
> tools like pip-run already support running a script for which you have the deps described with such comments > Packages are installed in a temporary virtual env and deleted after the run, like npx used to do for the JS world. Is it efficient? Download packages, install them only to delete several seconds later. Wastes precious SSD cells.
- userbinator 3y ago
  There's a massive amount of developers who unfortunately either don't know or don't care about efficiency. They'll blindly run commands with huge resource consumption with no second thought (or even an idea that such a thing is happening.) It wasn't long ago that a developer I was working with seemed to have entirely not comprehended the idea when I asked why he was searching for and downloading a dozen-MB PDF just to open (i.e. delete when closed) every time he wanted to look up one thing in it! I accumulate documentation for a project and keep most of it open throughout; I thought that was a usual thing to do, but apparently others will go online to search for that information every single time, then close the browser and reopen it whenver they need to look up something else. More publicly, it's also not long ago that Docker, and more relevantly, PyPI, have been getting worried about their bandwidth usage: https://news.ycombinator.com/item?id=24262757 https://news.ycombinator.com/item?id=24262757 https://news.ycombinator.com/item?id=27205586 https://news.ycombinator.com/item?id=27205586
keithalewis 3y ago
Sometimes there is no bandaid big enough to cover up a fundamental design decision in a language. Stick to solving problems it was designed for instead of crapping it up. Python isn't the only language , unless it's the only language you know.
- laichzeit0 3y ago
  The language part is the least of the problem. I would gladly develop in Turbo Pascal if it had the libraries I need. People use Python because of the ecosystem. PyTorch, Scikit learn, numpy, pandas, and many many other libraries built on top of those libraries.
declan_roberts 3y ago
[flagged]
Whoopee7177 3y ago
Why has the Python community not removed the GIL when migrating from Python 2 to Python 3?
- mixmastamyk 3y ago
  The guy who was smart enough/motivated to do it showed up only a couple of years ago.
  - kzrdude 3y ago
    That guy shows up every couple of years, almost like a prophecy https://github.com/larryhastings/gilectomy https://github.com/larryhastings/gilectomy
    - mixmastamyk 3y ago
      Only Mr. Gross succeeded, the others are not relevant.
      - kzrdude 3y ago
        Right. We'll see if he does, I hope it goes well.
- dragonwriter 3y ago
  Because at the time of the 2-3 migration, parallelism wasn’t viewed as being as important as it is today.
  - wtetzner 3y ago
    Is that really true? We already had multicore machines, and Herb Sutter's "The free lunch is over" article had been published for years by then.
    - Jtsummers 3y ago
wodenokoto 3y ago
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.
- BiteCode_dev 3y ago
  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 that need stability. You got one comment in this thread talking about "the python treadmill"! And all that for an open source project most don't contribute to and never paid a dime for.
  - antupis 3y ago
    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.
    - wanderingmind 3y ago
      You are thinking mojo [1] that's claims full python compatibility but can be extended for static typing and high performance scenarios [1] https://www.modular.com/mojo https://www.modular.com/mojo
      - mathisfun123 3y ago
        How many lines of mojo have you written?
    - BiteCode_dev 3y ago
      It wouldn't stay barebone, or would stop being used. That's the point.

400 points by BiteCode_dev 3y ago

wiz21c 3y ago

Is LPython comparable to Nuitka ?

dagw 3y ago
It seems to be closer to pythran than Nuitka. Mainly in that Lpython only supports a subset of python and focuses on performance of numeric code. Nuitka focuses primarily on being able to compile all of python, and has performance only as a secondary goal.

wiz21c 3y ago

For the record, I have found that on LPython's homepage, there is a pretty complete list of all "compilers" for Python. Really interesting list.

dang 3y ago

Recent and related: Intent to approve PEP 703: making the GIL optional - https://news.ycombinator.com/item?id=36913328 https://news.ycombinator.com/item?id=36913328 - July 2023 (488 comments)

nico_h 3y ago

The tenses in the headline and the article are very iffy. It’s more like there will be work to remove the GIL that will start after a particular PEP will be approved. The main reason we are still writing some stuff in java at our shop is because parallel processing sucks with multiprocessing, and trivial in java. I look forward to a future where it as trivial in or even simpler in python.

crabbone 3y ago

Every release brings Python closer to becoming Java. Another ten or so years, and we'll have feature parity with Java 8 or something. Maybe it will even be as fast!

ptx 3y ago
And conversely every release of Java brings it closer to becoming Python. With Java 4 we got regular expressions. With Java 5 we got varargs, string formatting, boxed numbers, syntax for looping over collections and imports of static methods. With Java 7 we got Timsort, the sorting algorithm from Python. With Java 8 we got first-class functions. With Java 9 we got a REPL. With Java 11 we got implicit compilation of source files so you can run them directly. In more recent releases, we have previews of features corresponding to f-strings and ctypes.
- crabbone 3y ago
  Don't get me wrong. I think Java and Python are both awful. I also think that by trying to exchange features they become even worse. I'm absolutely not excited and not looking forward to seeing any more versions of either of these languages. Well, maybe just a little bit, in an accelerationist kind of way.

deleted 3y ago

[deleted]

BiteCode_dev 3y ago

Summary: - Python without the GIL, for good - LPython: a new Python Compiler - Pydantic 2 is getting usable - PEP 387 defines "Soft Deprecation", getopt and optparse soft deprecated - Cython 3.0 released with better pure Python support - PEP 722 – Dependency specification for single-file scripts - Python VSCode support gets faster - Paint in the terminal

swyx 3y ago
great recap thanks!
- thiht 3y ago
  It's literally the summary at the top of the article Doesn't anyone click on links anymore?
  - swyx 3y ago
    just trying to compliment the author on a useful blogpost, calm down.
    - thiht 3y ago
      Oh I didn’t realize it was the author of the blogpost that also posted this summary. I thought someone copy pasted it because « it saves a click », as it sometimes happen!
      - BiteCode_dev 3y ago
        I started to write summaries for all articles everywhere I post. No need for people to waste their time if they are not interested in the topic. This also keeps my traffic stats clean: people that comes are the ones that are interested in the content. The number are smaller, but closer to what my real readership looks like. Since I have no ads, I don't aim for volume, so I rather know the truth.

andrewstuart 3y ago

From reading the thread on HN the other day, it sounds like removing the GIL isn't really of much value. Maybe for somewhat obscure multithreading cases. Is that right?

FartyMcFarter 3y ago
I would disagree with that. The GIL means you can't use Python multithreading in order to take advantage of more CPU time by parallelism. Obviously getting rid of the GIL makes that a real option, just as it is in other languages.
squeaky-clean 3y ago
Currently, yes that's kind of true. But it's really only considered obscure because the GIL makes it so you either have to do some weird non thread pattern or go with a different language, and people often go with a different language. Kind of a Catch-22 of "Well no one uses it that way, so why should we make it possible to use it that way? Well, no one uses it that way because it's impossible to use it that way"
kukkamario 3y ago
Well Python doesn't really do proper multi-threading currently thanks to GIL blocking any additional execution threads. So removing it would enable making Python code that is actually multi-threaded without resorting to extra processes and their overhead. So if you are writing small single process Python script then removing GIL shouldn't really change much. If you are doing some heavier computing or eg. running server back-end, then there are significant performance gains available with this change.
- School-Cotton 3y ago
  You don’t have to use separate processes to get the benefit of multithreading in Python today — you can also call into a library written in native code that drops the GIL (e.g. Numpy or Pytorch).
  - 3y ago

fbdab103 3y ago

Still not encouraged by the no-GIL, "We don't want another Python 2->3 situation", yet very little proffered on how to avoid that scenario. More documentation on writing thread-safe code, suggested tooling to lint for race conditions (for whatever it is worth), discussions with popular C libraries, dedicated support channels for top tier packages, what about the enormous long-tail of abandoned extensions which still work today, etc.

thiht 3y ago
> Note that if the program imports one single C-extension that uses the GIL on the no-GIL build, it's designed to switch back to the GIL automatically. So this is not a 2=>3 situation where non-compatible code breaks. Sounds good enough to me, am I missing something?
LexiMax 3y ago
In a past life I hacked on PHP for a living, and in the time it took Python 2 to ride off into the sunset, PHP got two major migrations under its belt in 5.2 to 5.3, and then again 5.6 to 7.0. It was amazing to see the contrast between the two languages. PHP gave you plenty of reasons to upgrade, and the amount of incompatible breaking changes was kept to a minimum, often paired with a way to easily shim older code to continue working. I really hope to see no-GIL make it into Python, but in the back of my mind I also worry about what lessons were learned from the 2 to 3 transition. Does the Python team have a more effective plan this time around?
- charrondev 3y ago
  I’ve taken an application codebase from PHP 5.3 to 8.2 now and it was relatively easy the whole way. The real key to minimize the pain was writing effective integration tests with high coverage. We didn’t have a good test suite to start but once we added some utilities to easily call our various endpoints (and internal API client if you will) and make assertions about the coverage came quickly. Popular frameworks like Laravel offer such test utilities out of the box now. That combined with static analysis tools like psalm make it so we can fearlessly move past major upgrades. One thing I was surprised at was just how much crap PHP allowed with just a notice (not even a warning for a long time). A lot of that stuff still works (although over time some notices have progressed to warnings or errors gradually). We have our test suite convert any notices or warnings to exceptions and fail the test case.

devwastaken 3y ago

This is exactly what I have been looking forward to. Allow me to do no-gil, let me the developer make that choice. There are issues with that certainly, but I am conscious of this fact and given an analysis of no-gil benefits it is significantly more beneficial to have no-gil for certain use cases. One of the most significant of these cases to me is threading outside an Operating system context. What if I want to use both of the cores to a Cortex M0? Multiprocessing can't help me, there are no processes. If I need locking, I will impliment it using the platform I have available to me. The second is the fact that CPU's are increasingly scaling in core count. When I have to use multiprocessing the program becomes far more complex than one would expect. Why am I doing message passing and shared memory when the OS and CPU supplies better tools already? It also pollutes the process ID's. Imagine if we built every application in Python - there would be hundreds of thousands of individual processes all to use multiple cores. Because this is a problem mostly unique to python we often end up having to build applications in other languages that otherwise would have been better in Python. I want a world where I can say "just use python" to almost anything. Telling new coders to drop their favorite language and use any other language to get the result they want immedietely kills the innovation they are working on. Instead of spending time creating the idea, they're spending time learning a languages I believe are unnecessary.

ActorNightly 3y ago
> let me the developer make that choice. The final push towards making no-GIL as the only option is the big issue here. An optional no-GIL is ok (although a waste of time), making it default is bad. >What if I want to use both of the cores to a Cortex M0 The solution to anything performant in Python is writing the C extension, just like Numpy did. Python isn't meant to be a performant language. The GIL allows you to write code without thinking about complexities of parallelism.

wmwmwm 3y ago

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 something but I couldn’t figure out how to get the multi-threaded performance out of Python but of course no-GIL looks interesting for this!

SanderNL 3y ago
It sounds I/O heavy, but you mention it being CPU-heavy in which case I’d say Python is just not the right tool for the job although you may be able to cope with multiprocessing.
iknownothow 3y ago
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 core, full isolation. 2. For multiple threads use `gunicorn` + `gevent` workers [2]. Provides multiprocessing + multithreaded functionality out of the box if you have IO intensive. It's not perfect but works very well in some situations. 3. Lastly, if CPU is where you have a bottleneck, that means you have some memory to spare (even if it's not much). Throw some LRU cache or cachetools [3] over functions that return the same result or functions that do expensive I/O. [1]: https://www.joelsleppy.com/blog/gunicorn-sync-workers/ https://www.joelsleppy.com/blog/gunicorn-sync-workers/ [2]: https://www.joelsleppy.com/blog/gunicorn-async-workers-with-gevent/ https://www.joelsleppy.com/blog/gunicorn-async-workers-with-... [3]: https://pypi.org/project/cachetools/ https://pypi.org/project/cachetools/
- xmaayy 3y ago
  > 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.

hanniabu 3y ago

Will writing multithreaded code become easier? Or will the developer UX remain the same?

dpedu 3y ago
The opposite, writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself that the GIL previously avoided. But, the tradeoff is that multithreaded programs could now actually achieve multithreaded performance gains.
- bvrmn 3y ago
  A single Go thread still replaces 10 Python threads, speaking very roughly. It's a quite particular narrow set of problems noGIL would solve.
  - sapiogram 3y ago
    Looks like ML workloads is the primary use case here, no amount of goroutines will help you there as long as the ecosystem doesn't exist.
- Jtsummers 3y ago
  > writing multithreaded code will get harder because you'll likely need to handle concurrency issues yourself I'd phrase this differently: Writing correct multithreaded code will be just as challenging (or not, depending on the person and their comfort with concurrent and parallel code development) as before, but now you won't be able to get away with sloppy multithreaded code that relied on the GIL to not break.
  - fbdab103 3y ago
    It was correctly written to the invariant promises of the platform at the time. If Python is altering the deal, that does not suddenly make the library writer at fault.

bigbillheck 3y ago

Python's been a little too happy to hard-deprecate things for my liking, so this soft-deprecation sounds pretty good.

mkoubaa 3y ago

And alternative C APIs are being proposed, which is as exciting as all of the above

cvnmalk 3y ago

Which, except for optparse, was all on the front page yesterday. So optparse is deprecated. More work I guess apart from auditing extensions for threading. Life is great in the Python treadmill.

maxnoe 3y ago
IIRC, optparse was going to be be removed in 3.5(?) but outcry was large . It has a depreciation warning in the docs since 3.2. It was in the "please just use argparse instead" state for a long time, this "just" adds an actual code warning.
nickcw 3y ago
I've tried to love argparse but it is so complicated. I always have to read the docs each time I use it. getopt has its own brutal simplicity.
- moonshinefe 3y ago
  If you aren't averse to using a third party package, on my personal projects I always found https://github.com/docopt/docopt https://github.com/docopt/docopt to be nice. You can kill 2 birds with one stone by documenting your scripts while also providing the argument structure / parsing.
- kzrdude 3y ago
  I think argparse works fine. What worries me is that it's also "soft-deprecated", because devs have said it should get no further development. I hope it stays around, because I use it by default as a no-dependencies solution that I know how it works.
  - mardifoufs 3y ago
    Wait.. source? If argparse isn't getting more development, what's the current alternative?
    - deleted 3y ago

schemescape 3y ago

The title says "GIL removed", but the article says "This means in the coming years, Python will have its GIL removed." I'm assuming the article is correct and the GIL has not been removed yet (but there is a plan to remove it in the future). If that's not the case, please correct me!

BiteCode_dev 3y ago
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 case scenario the article remove ambiguity. Plus the news popped up this week in HN front page, so a lot of people knew the context.
- School-Cotton 3y ago
  > 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).
  - BiteCode_dev 3y ago
    I guess I always felt like the chosen one deep down.
kzrdude 3y ago
There's been an announcement that they are probably going to decide to start a development plan that can eventually lead to removing the GIL later, if it works out. That plan is called PEP 703 and this is the factual basis: "We intend to accept PEP 703, although we’re still working on the acceptance details."
Jtsummers 3y ago

codedokode 3y ago

> tools like pip-run already support running a script for which you have the deps described with such comments > Packages are installed in a temporary virtual env and deleted after the run, like npx used to do for the JS world. Is it efficient? Download packages, install them only to delete several seconds later. Wastes precious SSD cells.

userbinator 3y ago
There's a massive amount of developers who unfortunately either don't know or don't care about efficiency. They'll blindly run commands with huge resource consumption with no second thought (or even an idea that such a thing is happening.) It wasn't long ago that a developer I was working with seemed to have entirely not comprehended the idea when I asked why he was searching for and downloading a dozen-MB PDF just to open (i.e. delete when closed) every time he wanted to look up one thing in it! I accumulate documentation for a project and keep most of it open throughout; I thought that was a usual thing to do, but apparently others will go online to search for that information every single time, then close the browser and reopen it whenver they need to look up something else. More publicly, it's also not long ago that Docker, and more relevantly, PyPI, have been getting worried about their bandwidth usage: https://news.ycombinator.com/item?id=24262757 https://news.ycombinator.com/item?id=24262757 https://news.ycombinator.com/item?id=27205586 https://news.ycombinator.com/item?id=27205586

keithalewis 3y ago

Sometimes there is no bandaid big enough to cover up a fundamental design decision in a language. Stick to solving problems it was designed for instead of crapping it up. Python isn't the only language , unless it's the only language you know.

laichzeit0 3y ago
The language part is the least of the problem. I would gladly develop in Turbo Pascal if it had the libraries I need. People use Python because of the ecosystem. PyTorch, Scikit learn, numpy, pandas, and many many other libraries built on top of those libraries.

declan_roberts 3y ago

[flagged]

Whoopee7177 3y ago

Why has the Python community not removed the GIL when migrating from Python 2 to Python 3?

mixmastamyk 3y ago
The guy who was smart enough/motivated to do it showed up only a couple of years ago.
- kzrdude 3y ago
  That guy shows up every couple of years, almost like a prophecy https://github.com/larryhastings/gilectomy https://github.com/larryhastings/gilectomy
  - mixmastamyk 3y ago
    Only Mr. Gross succeeded, the others are not relevant.
    - kzrdude 3y ago
      Right. We'll see if he does, I hope it goes well.
dragonwriter 3y ago
Because at the time of the 2-3 migration, parallelism wasn’t viewed as being as important as it is today.
- wtetzner 3y ago
  Is that really true? We already had multicore machines, and Herb Sutter's "The free lunch is over" article had been published for years by then.
  - Jtsummers 3y ago

wodenokoto 3y ago

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.

BiteCode_dev 3y ago
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 that need stability. You got one comment in this thread talking about "the python treadmill"! And all that for an open source project most don't contribute to and never paid a dime for.
- antupis 3y ago
  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.
  - wanderingmind 3y ago
    You are thinking mojo [1] that's claims full python compatibility but can be extended for static typing and high performance scenarios [1] https://www.modular.com/mojo https://www.modular.com/mojo
    - mathisfun123 3y ago
      How many lines of mojo have you written?
  - BiteCode_dev 3y ago
    It wouldn't stay barebone, or would stop being used. That's the point.