steering-council
ideas
steering-council | ideas | |
---|---|---|
3 | 81 | |
153 | 1,651 | |
1.3% | 0.4% | |
6.9 | 7.3 | |
3 months ago | 2 months ago | |
Makefile | ||
- | - |
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).
ideas
-
Type information for faster Python C extensions
Lower latency native calls in Python would be extremely useful, thank you for your work! Is the following GitHub issue the right place to monitor progress? https://github.com/faster-cpython/ideas/issues/546
I'm open to doing some benchmarking. Several of my libraries have pure CPython bindings (StringZilla, UCall, SimSIMD), and all perform low-latency SIMD-accelerated ops, so might be a good testing ground :)
-
How Many Lines of C It Takes to Execute a and B in Python?
Recent CPython development has been towards optimizations and addressing use cases that benefit from optimizations, some coming from the faster CPython initiative. You might just get your JIT[1].
[1] https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....
-
GIL removal and the Faster CPython project
The faster-cpython folks seem to be working towards a JIT (https://github.com/faster-cpython/ideas/tree/main/3.13) and both pyston and cinder have JITs. So I don't think anyone has ruled one out.
-
Our Plan for Python 3.13
faster-cpython team has done a lot of work to experiment on it: https://github.com/faster-cpython/ideas/issues/485#issuecomm...
It kind of sounds like migration to register based is a foregone conclusion, but it's not very clear to me.
-
Faster CPython at PyCon, part two
lots of big ideas are still remaining to be done. One example is the register based interpreter, see https://github.com/faster-cpython/ideas/issues/485
A previous plan called for the beginning of a JIT in 3.12, seen as "Trace optimized interpreter" here: https://github.com/faster-cpython/ideas/wiki/Workflow-for-3....
- EdgeDB – A graph-relational database built on top of Postgres
- Python 3.12 Nogil Benchmark
What are some alternatives?
full-speed-python - Full Speed Python: a book for self-learners
Nuitka - Nuitka is a Python compiler written in Python. It's fully compatible with Python 2.6, 2.7, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 3.10, and 3.11. You feed it your Python app, it does a lot of clever things, and spits out an executable or extension module.
opensergo-specification - Universal cloud-native microservice governance specification (微服务治理标准)
faster-cpython - How to make CPython faster.
nogil-3.12 - Multithreaded Python without the GIL (experimental rebase on 3.12)
Pyjion - Pyjion - A JIT for Python based upon CoreCLR
pex - A tool for generating .pex (Python EXecutable) files, lock files and venvs.
pyenv-virtualenv - a pyenv plugin to manage virtualenv (a.k.a. python-virtualenv)
ideas5 - Batch 5 of Ideas for Computing
jnumpy - Writing Python C extensions in Julia within 5 minutes.
nogil - Multithreaded Python without the GIL
cinder - Cinder is Meta's internal performance-oriented production version of CPython.