What about of using modern C++ in developing CPython ?
With C++ we can get the following benefits:
1) Readability - less code, most code is hidden by abstraction without losing performance
2) Maintainability - no code duplication in favor of using reusable classes
3) RAII - Resource Acquisition Is Initialization, predictable allocation and free resources
We've got to the stage now with PEP 646 that we're feeling pretty happy
with it. So far though we've mainly been workshopping it in typing-sig, so
as PEP 1 requires we're asking for some feedback here too before submitting
it to the steering council.
If you have time over the next couple of weeks, please take a look at the
current draft and let us know your thoughts:
https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
sections are out of date; https://github.com/python/peps/pull/1880
clarifies which grammar changes would be required, now that PEP 637 has
been rejected. We also have a second PR in progress at
https://github.com/python/peps/pull/1881 clarifying some of the motivation.)
Matthew and Pradeep
Hello Nick, Ethan,
The Python Steering Council reviewed PEP 467 -- Minor API improvements for binary sequences at our 2021-07-26 meeting.
Thank you for work on this PEP. We’re generally very favorable for adding to Python 3.11 the features and APIs described in the PEP. We have some requests for changes that we’d like you to consider.
* The Python-Version in the PEP needs to target Python 3.11 of course.
* We think it would be better if bytes.fromsize()’s second argument was a keyword-enabled or keyword-only argument. We understand the rationale given in the PEP for not doing so, but ultimately we think the readability of (at least allowing) a keyword argument to be more compelling. Some possible options include `fill`, `value`, or `byte`.
* We all really dislike the word “ord” as in `bytes.fromord()`. We understand the symmetry of this choice, but we also feel like we have an opportunity to make it more understandable, so we recommend `bytes.fromint()` and `bytearray.fromint()`.
* We think the `bchr()` built-in is not necessary. Given the `.fromint()` methods, it’s better not to duplicate the functionality, and everything has a cost. A built-in that exists only for the symmetry described in the PEP is just a little extra complexity for little value.
Let us know what you think about making these changes. We aren’t making acceptance contingent on these changes, but we do think they make the PEP and the new APIs better.
-Barry (on behalf of the Python Steering Council)
I think it will be an act of kindness to
deprecate Py_TRASHCAN_SAFE_BEGIN/END in 3.10 and tell people to use
TL;DR: There was a change in 3.8 that introduced the latter while leaving
the former for backwards compatibility, but also inadvertently breaking
them. This is not an easy bug to deal with in the wild, we found it because
we have a unit test in our codebase referencing https://
bugs.python.org/issue16602. A deprecation note pointing to the new macros
would have made it easier.
Is there any reason not to deprecate the old macros?
Our discussion on PEP 558 got me thinking
"What is the simplest thing that would work?".
This is what I came up (in the form of a draft PEP):
It doesn't have O(1) len(f_locals), and it does break
`PyEval_GetLocals()` but I think the that is a small price to pay for
simplicity and consistency.
What do you think?
Jeremy informed me<https://github.com/python/cpython/pull/27436#issuecomment-889815333> that due to a race condition on a test file and the CPython repo configuration for newline conversion, build bots on Windows may now be failing.
If you run such a buildbot, please consider running this command on your repo to bypass the issue:
git rm -r :/ ; git checkout HEAD -- :/
You may want to consider adding this command after every update to the repo to avoid the stale state.
As you might know, PEP 581 (Using GitHub Issues for CPython) has been
approved. I've been working with Ewa, Ee, the Working Group, the
Steering Council, and the GitHub folks to make this happen, and the SC
encouraged me to give you all a quick update.
This effort is being tracked at
<https://github.com/psf/gh-migration/projects/1>: this board reflects
the current status of the project. The PEPs (including PEP 588 --
GitHub Issues Migration Plan) haven't been updated yet and might
contain outdated information, so please refer to the psf/gh-migration
repo for the latest updates.
During the next phase I will work with the WG to sort out all the
major issues that we might encounter, and then I will once again reach
out to you to gather feedback from the wider audience that follows
these mailing lists.
Hi. I have an Alpha/OSF machine up and running.
It is little slow, but it works ok.
I would like to run Python3 on it.
I have it "compiling and working". It was easy enough so far.
Admitted, I haven't figured out what is happening with the posixsubprocess module.
Yes? No? Maybe?
I can possibly provide ongoing "support" (I don't expect it will be much) and a buildbot (if really required),
if I can get it working a bit more, if this is approved, etc. I haven't looked yet at what buildbot involves.
I would like to repeal PEP 509. We don't really have a process for
repealing a PEP. Presumably I would just write another PEP.
Before I do so, I would like to know if anyone thinks we should keep
The dictionary version number is currently unused in CPython and just
wastes memory. I am not claiming that we will never need it, just that
we shouldn't be required to have it. It should be an internal
implementation detail that we can add or remove depending on requirements.
I would love to have this in Python 3.10, but the interaction with
"decimal" context has a risk I don't know how to evaluate, neither the
impact of a new "context" parameter when launching a new thread. It
could collide with a "frequently used" parameter name.
I know that we are quite late in 3.10 window since rc1 is planned in a
couple of days, but I think this enhancement is sensible. In fact, I
discovered it after being annoyed myself with this issue (threads should
have their own contexts) and studying the code to write a patch myself.
In particular, "concurrent.futures" threads should have independent
contexts, like asyncio futures have. That would allow, for instance, to
have a "requests.Session" object per thread since that object is not
thread-safe (my use case today) and reuse it in different futures that
happens to run in the same thread.
Since "contextvars" is "threading.local" correctly done, let's do it for
If legacy code expects a thread to be able to modify parent context,
just pass that context to the thread explicitly.
Jesús Cea Avión _/_/ _/_/_/ _/_/_/
jcea(a)jcea.es - https://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/
jabber / xmpp:firstname.lastname@example.org _/_/ _/_/ _/_/ _/_/ _/_/
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz