Thank you for submitting PEP 651. The Steering Council has spent the past two weeks reviewing PEP 651. After careful consideration, we have decided to reject the PEP. The following were the key points that led us to this decision:
* The benefits are not compelling enough. Deep recursion is not a common tool in
Python, and even with PEP 651 it would not be efficient enough to make it a common
* The benefit of PEP 651 is negated as soon as a non-Python function is involved in the
recursion, making the likelihood of it being useful even smaller. It also creates
easy pitfalls for users who do end up relying on recursion.
* We believe the PEP understates the disruption created by the technical solution of
multiple Python stack frames per C call. Although this may be solvable, it will
certainly cause substantial disruption to existing debuggers, tracers, and state
inspection tools as they need to adapt to this change (which may not be trivial).
* As the way to approach this will be platform-specific (as some parts of the proposal
are not portable), this can cause generic Python code to behave differently on
different platforms, making this kind of code less portable and less predictable.
In the end, the benefit of the PEP does not outweigh the cost of the potential breakage, confusion, and unpredictability of the feature.
With our appreciation,
The Python Steering Council
After several months of absence - my first manual build surprised me by
the addition of the -qalias=noansi.
Before I open an issue - maybe it is not that important - I am trying to
find what brought it in. It looks to be a change in behavior in
configure(.ac) - starting with Python3.9.
Historical builds - and make.out:
Prior to Python3.9
xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64
-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64
i.e., the flags became:
xlc_r -c -DNDEBUG -O -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64
-I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64 -qalias=noansi
Note the flags have been repeating themselves for a long time, but now -
after the repeated flags `-qalias=noansi -qmaxmem=-1` is being added. my
gut repsonse is that I do not like seeing 'noansi' being passed as a
flag to the compiler and I am trying to understand why - also how.
Fyi: using `git log` I have tried to get any clue re: CFLAGS_NODIST
and/or -qalias=noansi - but I do not seem to be skilled enough to find
Help is appreciated - and, thereafter, as needed, I'll open an issue.
M Felt aka aixtools
Currently, the only way to concatenate an integer to a bytes object is by
the integer to bytes with a function call before concatenating. And there
is no way to
make a mutable bytes object without a function call. And bytearray function
calls are 9-10x slower than b-strings.
I propose an array-type string like the, or for the bytearray. It would
work as a
mutable b-string, as
foo = a"\x00\x01\x02abcÿ" # a-string, a mutable bytes object.
foo = 123 # Item assignment
foo+= 255 # Works the same as
foo+= a"\x255\x00" # Concatenation with itself
foo+= b"\x255\x00" # Cross compatibility with bytes
This would be processed the same as, or would be the bytearray,
We would like to request feedback on PEP 654 -- Exception Groups and
It proposes language extensions that allow programs to raise and handle
exceptions simultaneously, motivated by the needs of asyncio and other
but with other use cases as well.
* A new standard exception type, ExceptionGroup, to represent multiple
* Updates to the traceback printing code to display (possibly nested)
* A new syntax except* for handling ExceptionGroups.
A reference implementation (unreviewed) can be found at:
Thank you for your help
Irit, Yury & Guido
I was curious how and why return annotations use the arrow `->` symbol,
so I went spelunking into the depths of the Python-Ideas and Python-Dev
Much to my surprise, I couldn't find any discussion or debate about it.
Eventually I tracked the discussion back to a mailing list I didn't even
know existed, Types-Sig, all the way back to 13th Dec 1999, where I
found this email by Tim Hochberg:
suggesting the arrow symbol for all type declarations. This appears to
be the first suggestion of the arrow symbol for type annotations in
I am surprised that type checking was being discussed so long ago.
Python was not even a decade old, and if my calculations are correct,
the versions at the time would have been 1.5.2 and 1.6.0.
But I am especially amazed that the choice of symbol seems to have been
accepted with very little argument or debate about alternative colours
for the bike-shed. I can't find any suggestions for alternative symbols
such as `=>` `-->` `==>` `->>` etc, and very little for keywords such as
`as`. The day after Tim posted, Tony Lownds suggested `as` and then
immediately suggested using Tim's arrow symbol for the return type only:
and then as far as I can tell, we've never looked back.
If there is anyone whose memory reaches back that far, does that sound
The PEPs repo  has a README  with instructions for configuring a local installation of the python.org website such that you can develop PEPs locally and see how they will appear on python.org locally. However the README's instructions reference a python.org configuration setting (PEP_REPO_PATH) that appears to no longer exist.
So I reimplemented support for the PEP_REPO_PATH setting for local python.org installations and have a pull request out for review at  which has been seeking a reviewer for about 2 weeks. Is there someone on this list (or at some other particular location) who would be willing to give me a review?
David Foster | Seattle, WA, USA
Contributor to TypedDict support for mypy
I’m happy to announce that we’ve opened the sign-up forms for the 2021 Python Language Summit!
When: Tuesday, May 11, 2021 (4 hours) and Wednesday, May 12, 2021 (4 hours). Exact times TBD depending on attendee timezones.
Where: Online via Zoom (link will be sent via email to attendees)
Co-chairs: Mariatta Wijaya & Łukasz Langa
Blogger: Joanna Jablonski
Sign up to attend and actively participate: https://forms.gle/cgmGnmQMDhD2mhHY8 <https://forms.gle/cgmGnmQMDhD2mhHY8> (closes after March 22nd, 2021 AoE)
Propose a topic: https://forms.gle/Jui9mxsHrB4fVvAB8 <https://forms.gle/Jui9mxsHrB4fVvAB8> (closes after March 22nd, 2021 AoE)
To get an idea of past Python Language Summits, you can read these blog posts:
2020: Python Software Foundation News: The 2020 Python Language Summit <https://pyfound.blogspot.com/2020/04/the-2020-python-language-summit.html>
2019: http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html <http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html>
2018: The 2018 Python Language Summit [LWN.net] <https://lwn.net/Articles/754152/>
2017: The 2017 Python Language Summit [LWN.net] <https://lwn.net/Articles/723251/>
Do I need to sign up if I’m a Python core developer?
Yes please! While in the past we have limited attendance to 50 people, this time, due to virtual format, we will be a bit more flexible, but will still keep it small and manageable. We aren’t planning to go beyond 80 participants. Please register to reserve your space.
Can I sign up if I’m not a Python core developer?
Yes you can. In the past, we had quite a number of participants who were not Python core devs. Among them were maintainers and representatives from BeeWare, CircuitPython, PSF board member, PyCharm, PyPA, etc. Register if you want to participate. Note that until you hear back from us, your attendance is not confirmed. As explained in the question above, our “space” is more flexible than usual, but in the interest of maintaining a vigorous discussion space, we might still be unable to invite everyone who signs up.
What kind of topics are covered?
Python Language Summit is a special event with very specific audience: Python core developers. Ideally your topic is not an “announcement” or “project status” but rather something that will encourage further discussion and questions. The more controversial, the better. An open issue, group of issues, or a PEP that is awaiting decision are all good topics to propose. You can also further explain why this is better discussed in person instead of online.
According to last year’s feedback, our audience prefer more discussions and shorter talks.
Who can present a talk?
Anyone, even if you’re not a Python core developer. However, please understand that we will have to be selective as space and time are limited. In particular, we are prioritizing active core contributors, as well as those who we believe will be able to improve the quality of the discussions at the event and bring a more diverse perspective to core Python developers. Note that your topic is not confirmed until you hear back from us.
Code of Conduct
PyCon’s Code of Conduct <https://us.pycon.org/2020/about/code-of-conduct/> applies and will be enforced.
@mariatta <https://discuss.python.org/u/mariatta> & @ambv <https://discuss.python.org/u/ambv>
I love the Python scripting language, but there’s something that would make
it much better. Almost every other programming language uses curly braces
to enclose blocks of code and semicolons after the lines of code. That
You can have as much white space as you want.
You don’t need to worry about indentation, and you can indent whenever
I hope that you consider these issues and fix them in Python 4 (if you ever
Sincerely, Anthony, age 10.
mm m #
## m mm mm#mm # mm mmm m mm m m
# # #" # # #" # #" "# #" # "m m"
#mm# # # # # # # # # # #m#
# # # # "mm # # "#m#" # # "#
Good Afternoon Python Devs,
I'm requesting that someone review the pull request linked to this issue: https://bugs.python.org/issue42994 (github PR: https://github.com/python/cpython/pull/24287).
I'm following the contributing guidelines instructions to email this address if the PR hasn't been addressed in a month (+1 week after pinging it again). Thankfully this PR is tiny, at 9 lines total (and even then, it's just 9 new entries to a dictionary).
Thank you for your time,