From Thomas Wouters, on behalf of and with full support of the Python Steering Council:
This discussion seems to have died down a little, but I still want to make a few things clear:
Yes, this is a political decision. Very many decisions are political. The existence of an open-source project is inherently political. The decision to try and make python-dev more welcoming, more open, more helpful is also a political decision -- one that the SC feels is absolutely necessary for the long-term health of the Python language. Not wanting to be bothered by political decisions is a political decision; it’s a decision that you’re happy with politics as they are. I’m afraid you can’t avoid politics.
This isn’t just about ‘master’ being rooted in slavery. This is about what the community sees and does. As I mentioned before, we’re not leading the pack in this, we’re merely following along with others (like, say, Django). There are undoubtedly other terms and practices that are genuinely offensive, and the decision on how to handle them will be taken on a case-by-case basis, weighing the cost and the benefit in each case.
While you may feel the benefit of this change is small and that it has no real impact, we believe that there is little cost to making this change. We believe this change, while a minor inconvenience to some, helps demonstrate our commitment to acting in the best interests of Python's future. Failure to make a small sacrifice, such as this, signals that the Python core development community would be unlikely to undertake real change for greater benefits.
This isn’t happening because GitHub/Microsoft made a political decision. It’s happening because it is incredibly easy to make this move, many projects have already done this, and it reflects badly on any project not making this change.
Speaking for the whole SC in this,
CPython is slow. We all know that, yet little is done to fix it.
I'd like to change that.
I have a plan to speed up CPython by a factor of five over the next few
years. But it needs funding.
I am aware that there have been several promised speed ups in the past
that have failed. You might wonder why this is different.
Here are three reasons:
1. I already have working code for the first stage.
2. I'm not promising a silver bullet. I recognize that this is a
substantial amount of work and needs funding.
3. I have extensive experience in VM implementation, not to mention a
PhD in the subject.
My ideas for possible funding, as well as the actual plan of
development, can be found here:
I'd love to hear your thoughts on this.
We would like to present for feedback a new version of PEP 654, which
incorporates the feedback we received in the discussions so far:
The reference implementation has also been updated along with the PEP.
The changes we made since the first post are:
1. Instead of ExceptionGroup(BaseException), we will have two new builtin
types: BaseExceptionGroup(BaseException) and
This is so that "except Exception" catches ExceptionGroups (but not
BaseExceptionGroups). BaseExceptionGroup.__new__ inspects the wrapped
exceptions, and if they are all Exception subclasses, it creates an
ExceptionGroup instead of a BaseExceptionGroup.
2. The exception group classes are not final - they can be subclassed and
split()/subgroup() work correctly if the subclass overrides the derive()
instance method as described here:
3. We had some good suggestions on formatting exception groups, which we
have implemented as you can see in the output shown for the examples in the
4. We expanded the section on handling Exception Groups, to show how
subgroup can be used (with side effects) to do something for each leaf
exception, and how to iterate correctly when the tracebacks of leaf
exceptions are needed:
5. We expanded the sections on rationale and backwards compatibility to
explain our premise and expectations regarding how exception groups will be
used and how the transition to using them will be managed.
6. We added several items to the rejected ideas section.
We did not receive any comments (or make any changes) to the proposed
semantics of except*, hopefully this is because everyone thought they are
Irit, Yury and Guido
I just got the reply below sent directly to my personal account, and I'm
confused about what's going on. If it's just a one off I'll chalk it up to
random internet weirdness, but if other folks are getting these too it
might be something the list admins should look into? Or... something?
---------- Forwarded message ---------
From: Hoi lam Poon <gillcovid19(a)gmail.com>
Date: Fri, Apr 23, 2021, 02:01
Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
To: Nathaniel Smith <njs(a)pobox.com>
Stop pretending, I can definitely get the key control file, your working
group, all past actions and instructions cannot be cleared in front of me
at all. You have been playing around for a few days, and I won’t stop you.
Your face? I won’t, you know, you can’t drive me away, and that file is
all, after I get it, you will be convicted even if you disband, I swear
在 2021年4月23日 週五 16:23，Nathaniel Smith <njs(a)pobox.com> 寫道：
> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum <guido(a)python.org> wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith <njs(a)pobox.com> wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compromises. I only elaborated
> >> on it b/c in your last email you said you didn't understand why this
> >> was a problem :-). And except* is definitely useful. But I think there
> >> are options for 'except' that haven't been considered fully.
> > Do you have any suggestions, or are you just telling us to think harder?
> Because we've already thought as hard as we could and within all the
> constraints (backwards compatibility and otherwise) we just couldn't think
> of a better one.
> The main possibility that I don't think we've examined fully is to
> make 'except' blocks fire multiple times when there are multiple
> exceptions. We ruled it out early b/c it's incompatible with nested
> EGs, but if flat EGs are better anyway, then the balance shifts around
> and it might land somewhere different. it's a tricky discussion
> though, b/c both the current proposal and the alternative have very
> complex implications and downsides. So we probably shouldn't get too
> distracted by that until after the flat vs nested discussion has
> settled down more.
> I'm not trying to filibuster here -- I really want some form of EGs to
> land. I think python has the potential to be the most elegant and
> accessible language around for writing concurrent programs, and EGs
> are a key part of that. I don't want to fight about anything; I just
> want to work together to make sure we have a full picture of our
> options, so we can be confident we're making the best choice.
> > The real cost here is that we would need a new "TracebackGroup" concept,
> since the internal data structures and APIs keep the traceback chain and
> the exception object separated until the exception is caught. In our early
> design stages we actually explored this and the complexity of the data
> structures was painful. We eventually realized that we didn't need this
> concept at all, and the result is much clearer, despite what you seem to
> I'm not talking about TracebackGroups (at least, I think I'm not?). I
> think it can be done with exactly our current data structures, nothing
> - When an EG is raised, build the traceback for just that EG while
> it's unwinding. This means if any C code peeks at exc_info while it's
> in flight, it'll only see the current branch of the traceback tree,
> but that seems fine.
> - When the exception is caught and we go to write back the traceback
> to its __traceback__ attribute, instead "peek through" the EG and
> append the built-up traceback entries onto each of the constituent
> You could get cleverer for efficiency, but that basic concept seems
> pretty simple and viable to me. What am I missing?
> Nathaniel J. Smith -- https://vorpus.org
> Python-Dev mailing list -- python-dev(a)python.org
> To unsubscribe send an email to python-dev-leave(a)python.org
> Message archived at
> Code of Conduct: http://python.org/psf/codeofconduct/
When one writes one's "blurb" for the changelog, in what tense should it
be? I mostly see entries in present tense:
bpo-43660: Fix crash that happens when replacing sys.stderr with a
callable that can remove the object while an exception is being
printed. Patch by Pablo Galindo.
bpo-41561: Add workaround for Ubuntu’s custom OpenSSL security level
But occasionally I see entries in past tense:
bpo-26053: Fixed bug where the pdb interactive run command echoed
the args from the shell command line, even if those have been
overridden at the pdb prompt.
bpo-40630: Added tracemalloc.reset_peak() to set the peak size of
traced memory blocks to the current size, to measure the peak of
specific pieces of code.
I couldn't find any guidance in the Python Dev Guide after sixty seconds
of poking around.
Obviously this isn't a big deal. But it might be nice to try and nudge
everybody in the same direction. It'd be pleasant if the changelog read
in a more unified voice, and using the same tense and sentence structure
would help towards that goal.
If we arrived at a firm decision, maybe "blurb" et al could add a little
text suggesting the proper style.
Thank you for your submission of PEP 648 (Extensible customizations of the interpreter at startup). The Python Steering Council has reviewed the PEP and before we can pronounce on it, we have some additional questions and comments we’d like you to address. Once these questions are settled, we are requesting that you post the PEP to python-dev for another round of comments.
In general, the SC is in favor of deprecating the executable hack capabilities of pth files, and this PEP is currently the most concrete proposal to get there. We would like to eventually go farther, including deprecation of pth files entirely, but that is outside the scope of this PEP.
General PEP feedback
The introduction of the section titled “Benefits of __sitecustomize__” seems out of place. It forward references the solution without explanation. It also says “The use of a __sitecustomize__ will allow…”; the question is, a __sitecustomize__ what? Directory? File? Perhaps it should be moved to later in the PEP after the semantics of __sitecustomize__ is defined?
Some of the terminology used in the PEP could be clarified. For example, I suggest using the term “directory” instead of “folder” throughout the PEP, and use the term “module” or “file” instead of “script” to describe the things inside __sitecustomize__ directories that Python imports, since “scripts” typically describe standalone files that implement applications. For example, must the files be named with .py extension (or presumably .pyc, .pyo) under the normal Python module import rules? (Later in the PEP you do allude to the requirement that the file name must end in .py, but it would be much better to explain this right up front, in a formal specification.)
Another ambiguity is what the PEP means by “executing” said “scripts”. Does that mean importing them? Reading them then exec()’ing them? Something else? This section should be clear that Python will import the modules it found, if that’s indeed what the PEP is proposing.
The “Backward compatibility” section has this incomplete sentence: “Ignoring those lines in pth files.”
There’s this odd grammar in the “Do nothing” section: “After analysing the impact of this change, we believe it is worth given the enhanced experience it brings.” Perhaps it should read “...it is worth it, given the…”?
Definition of “site path”
The PEP should precisely define what it means when it says “...a folder named __sitecustomize__ located in any site path”. What exactly is a “site path”? Is this any directory on sys.path? Is it a directory named site-packages?
This phrase is also ambiguous: “As the folder will be within sys.path, given that it is located in site paths...”. “sys.path” isn’t a thing that can hold a folder, since it’s just a list of strings, and it also can get extended by any number of means, e.g. by setting the PYTHONPATH environment variable at interpreter startup time. So for example, how does PYTHONPATH affect the algorithm?
What is the rationale for adding multiple __sitecustomize__ directories, rather than a single directory (or possibly two, one in Python’s system location and one in the user location)? This would simplify the discovery process, and tools like pip can warn the user if a name collision were to occur.
I think the PEP needs to be much more crisp and precise in defining the when and how __sitecustomize__ directories are discovered at start up time.
Order of Execution
I think this section should outline the entire startup execution order. Exactly when do pth files still get evaluated in relationship to __sitecustomize__ discovery? How do pth file sys.path extensions affect the search for __sitecustomize__ directories? This section also says files in __sitecustomize__ will be executed in “file name sorted order”, but the PEP is unclear whether all such files found in every __sitecustomize__ directory will be sorted together, or only within a single __sitecustomize__ directory. Presumably file system encodings are used to determine file name sort order, but I think the PEP should be explicit about this.
I’d like to see the execution order for the entire proposed new Python startup sequence as a recipe, or perhaps even some Python pseudo-code.
Impact on startup time
We still think that startup performance can be a concern. This section needs more data. For example, while the executable part of pth files is being deprecated, both pth and __sitecustomize__ modules will exist. How does this affect startup time in a world where both have to be discovered and processed?
The PEP says: “If the user has custom scripts, we think that the impact on the performance of walking each of the folders is acceptable, as the user wants to use this feature.” Does the user really want to use this feature? Won’t it more likely be the system administrator or Python distribution and packaging ecosystem that chooses to use the __sitecustomize__ feature? Maybe the user won’t even know that it’s being used by the packages being installed?
The PEP says: ““Running "./python -c pass" with perf on 50 iterations, repeating 50 times the command on each and getting the geometric mean on a commodity laptop did not reveal any substantial raise on CPU time.” We request more information on the experiments performed, and specific numbers so that the startup impact can be reproduced and confirmed by others. E.g. did you run this experiment on a branch of CPython 3.10 with the PEP 648 reference implementation? Did you convert existing uses of executable pth files to __sitecustomize__ modules? How many such modules did you try it with? How many __sitecustomize__ directories were in your tests?
Other questions and issues
How does this feature interact with virtual environments? What do packaging tools have to do to support this PEP? The PEP mentions setuptools, but what about other packaging tools in common use?
The PEP says “This impact will be reduced in the future as we will remove two other imports: "sitecustomize.py" and "usercustomize.py”.” Why not explicitly deprecate these and executable pth files in PEP 648 and begin the countdown at the same time __sitecustomize__ is added to Python?
The PEP says: “To facilitate debugging of the Python startup, a new option will be added to the main of the site module to list all scripts that will be executed as part of the __sitecustomize__ initialization.” The PEP should be explicit about what command line switch is being proposed. We think this should probably be an -X option.
Do you have any concerns that this feature will be overused? Does separating the execution feature from the path extension feature make it more or less likely to be used by third party library authors?
Will the runtime have any access to the list of __sitecustomize__ modules being executed? I.e. will you collect their paths in a new sys module attribute? Will there be any functions to import or list __sitecustomize__ directories or modules after start has completed?
We think io.open_code() should be used so that reading the files can be audited.
The Python Steering Council again wants to thank you for your PEP contribution! We hope you find this feedback constructive and helpful. We look forward to your responses, and an updated PEP.
-Barry (on behalf of the Python Steering Council)
An excerpt from bpo-31369: re.RegexFlag and `__all__`
> One thing I discovered when developing this example: there doesn't seem to be a flag to
> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works
> fine at runtime).
Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set?
What should we call it?
I've merged the main part of PEP-652 implementation. The Limited C API
(introduced in PEP 384 and used for extension modules that work across
Python versions without recompilation) is now explicitly defined and
When changing/extending the limited API:
- Stop and think! This API will need to be suppported forever (or until
Python 3 reaches end of life, if that comes sooner). A checklist of what
to think about is being added to the devguide .
- Add/change an entry in `Misc/stable_abi.txt`.
- Run `make regen-limited-abi` [sic].
You can run related checks with `make check-limited-abi`. If that or the
"Check if generated files are up to date" CI test gives you errors,
please let me know!
More tests & docs are coming up.