steering-council
nogil
steering-council | nogil | |
---|---|---|
3 | 31 | |
153 | 2,854 | |
1.3% | - | |
6.9 | 5.7 | |
3 months ago | 2 months ago | |
Makefile | Python | |
- | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
steering-council
-
Our Plan for Python 3.13
GVR called it a fork two weeks ago in his justification for not accepting it [1]. If that surprises you, the backstory is summarized pretty well in the article [2] and FAQ [3].
I'm really not trying to be secretive. We can debate whatever you want, but we have to at least acknowledge CPython's stated position.
[1] https://github.com/python/steering-council/issues/188#issuec...
[2] https://www.artima.com/weblogs/viewpost.jsp?thread=214235
[3] https://docs.python.org/3/faq/library.html#can-t-we-get-rid-...
-
Python PEP for Making the GIL Optional Doesn't Get Enough Support
Thanks for reviewing the PEP. The PEP was posted five months ago, and it has been 20 months since an end-to-end working implementation (that works with a large number of extensions) was discussed on python-dev. I appreciate everyone who has taken the time to review the PEP and offer comments and suggestions.
You wrote that the Steering Council's decision does not mean "no," but the steering council has not set a bar for acceptance, stated what evidence is actually needed, nor said when a final decision will be made. Given the expressed demand for PEP 703, it makes sense to me for the steering committee to develop a timeline for identifying the factors it may need to consider and for determining the steps that would be required for the change to happen smoothly.
Without these timelines and milestones in place, I would like to explain that the effect of the Steering Council's answer is a "no" in practice. I have been funded to work on this for the past few years with the milestone of submitting the PEP along with a comprehensive implementation to convince the Python community. Without specific concerns or a clear bar for acceptance, I (and my funding organization) will have to treat the current decision-in-limbo as a “no” and will be unable to pursue the PEP further.
Github Link: https://github.com/python/steering-council/issues/188#issuec...
-
PEP 681 – Data Class Transforms (accepted)
Hmm, likely because it was already submitted to the steering council since April and because the addition is relatively trivial (at runtime, it's almost a no-op).
nogil
- Proof-of-Concept Multithreaded Python Without the GIL
-
Our Plan for Python 3.13
This might be a dumb question, but why would removing the GIL break FFI? Is it just that existing no-GIL implementations/proposals have discarded/ignored it, or is there a fundamental requirement, e.g. C programs unavoidably interact directly with the GIL? I know that the C-API is only stable between minor releases [0] compiled in the same manner [1], so it's not like the ecosystem is dependent upon it never changing.
I cannot seem to find much discussion about this. I have found a no-GIL interpreter that works with numpy, scikit, etc. [2][3] so it doesn't seem to be a hard limit. (That said, it was not stated if that particular no-GIL implementation requires specially built versions of C-API libs or if it's a drop-in replacement.)
[0]: https://docs.python.org/3/c-api/stable.html#c-api-stability
[1]: https://docs.python.org/3/c-api/stable.html#platform-conside...
[2]: https://github.com/colesbury/nogil
[3]: https://discuss.python.org/t/pep-703-making-the-global-inter...
-
Real Multithreading Is Coming to Python
https://github.com/colesbury/nogil does manage to get rid of the GIL, but it's not certain to make it into Python core. The main problem is the amount of existing libraries that depend on the existence of the GIL without realizing it - breaking those would be extremely disruptive.
-
[D] The hype around Mojo lang
CPython is also investigating the removal of the GIL (PEP703, nogil). I think requiring the GIL is a wider thing that libraries will need to address anyway. But also, for the same reason as above I'd be surprised if the Modular team thought that saying "you can run all your python code unchanged" was a good idea if there was a secret "except for code that uses numpy" muttered under the breath.
- PEP 684 was accepted – Per-interpreter GIL in Python 3.12
- PEP 703 – Making the Global Interpreter Lock Optional in CPython
-
Python 3.11.0 final is now available
I'm worried about the speedup
My understanding is that it's based on the most recent attempt to remove the GIL by Sam Gross
https://github.com/colesbury/nogil
In addition to some ways to try to not have nogil have as much overhead he added a lot of unrelated speed improvements so that python without the gil would still be faster not slower in single thread mode. They seem to have merged those performance patches first that means if they add his Gil removal patches in say python 3.12 it will still be substantially slower then 3.11 although faster then 3.10. I hope that doesn't stop them from removing the gil (at least by default)
- Removed the GIL back in 1996 from Python 1.4, primarily to create a re-entrant Python interpreter.
- I Tried Removing Python's GIL Back in 1996
-
Faster CPython 3.12 Plan
Looks like it's still active to me:
https://github.com/colesbury/nogil/