In Python 2.5 `0or` was accepted by the Python parser. It became an
error in 2.6 because "0o" became recognizing as an incomplete octal
number. `1or` still is accepted.
On other hand, `1if 2else 3` is accepted despites the fact that "2e" can
be recognized as an incomplete floating point number. In this case the
tokenizer pushes "e" back and returns "2".
Shouldn't it do the same with "0o"? It is possible to make `0or` be
parseable again. Python implementation is able to tokenize this example:
$ echo '0or' | ./python -m tokenize
1,0-1,1: NUMBER '0'
1,1-1,3: NAME 'or'
1,3-1,4: OP '['
1,4-1,5: OP ']'
1,5-1,6: NEWLINE '\n'
2,0-2,0: ENDMARKER ''
On other hand, all these examples look weird. There is an assymmetry:
`1or 2` is a valid syntax, but `1 or2` is not. It is hard to recognize
visually the boundary between a number and the following identifier or
keyword, especially if numbers can contain letters ("b", "e", "j", "o",
"x") and underscores, and identifiers can contain digits. On both sides
of the boundary can be letters, digits, and underscores.
I propose to change the Python syntax by adding a requirement that there
should be a whitespace or delimiter between a numeric literal and the
Can you give us a status update for your PEP 649? I don't recall reading
anything about it in the past few weeks. I am super excited about this
solution to the problem (even if there are a few issues to work through)
and I think it will provide better backwards compatibility than the current
plan for Python 3.10 (PEP 563, from __future__ import annotations, causing
all annotations to be stringified).
If we don't get this into 3.10, we'd have a much more complicated
transition. There are only two more alphas before 3.10b1 gets released! And
we'd have to get this approved by the Steering Council, which can take a
few weeks (cut them some slack, they have a big backlog). Fortunately you
already have an implementation that can be landed quickly once the PEP is
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
I hope you are all well, I currently have an issue / merge request that has
become stale and as per the guidelines I am sending this e-mail to request
someone to review it for me please.
Issue Number: 42861 (https://bugs.python.org/issue42861)
Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
This is my first contribution to CPython and I am very keen to get this
added as I think it is an almost essential enhancement missing from the
ipaddress module. I would greatly appreciate if someone can take a look
and give me feedback, I am more than happy to help explain things, as I
appreciate this is not the most straightforward thing to do.
Effectively, this method allows you to get the next closest network of any
prefix size, it works by effectively adding 1 to the host portion of the
network. There is actually a very nice guide someone made on stackexchange
explaining how to do this calculation manually, I simply followed this
logic and have tested it as much as possible and it seems to work great.
Please let me know if there is anything else I can do to help get this
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>
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
After much deliberation, the Python Steering Council is happy to announce that we have chosen to accept PEP 634, and its companion PEPs 635 and 636, collectively known as the Pattern Matching PEPs. We acknowledge that Pattern Matching is an extensive change to Python and that reaching consensus across the entire community is close to impossible. Different people have reservations or concerns around different aspects of the semantics and the syntax (as does the Steering Council). In spite of this, after much deliberation, reviewing all conversations around these PEPs, as well as competing proposals and existing poll results, and after several in-person discussions with the PEP authors, we are confident that Pattern Matching as specified in PEP 634, et al, will be a great addition to the Python language.
We also recognize that such a large new feature needs to be accompanied by comprehensive documentation and specification, both in the tutorial section of the documentation and in the language reference. We consider that the presence of such high-quality documentation must be present on the first release of Python 3.10, and therefore its absence should be considered a release blocker. We do not consider the PEPs or any possible external documentation to be sufficient.
At the same time, we’re rejecting PEPs 640 and 642. Both PEPs have received little support from core developers. PEP 642’s proposed syntax does not seem like the right way to solve the jagged edges in PEP 634’s syntax, although the SC understands the desire to improve those aspects of the Pattern Matching proposal.
Regarding that, we would also like to mention that changes building on top of PEP 634 (even PEPs 640 and 642 if they now gain support) can still be submitted via the PEP process for review using the regular channels (discussions in python-dev or the https://discuss.python.org/ server), followed by a formal submission to the Steering Council for consideration, taking into account that backwards-incompatible changes can only be made before the feature freeze point of Python 3.10. See PEP 619 (https://www.python.org/dev/peps/pep-0619/) for details on the release schedule for Python 3.10.
We know that Pattern Matching has been a challenging feature that has sparked considerable discussions and design conversations, leading to several revisions from feedback stemming from the community, core devs, and the Steering Council. We are very happy to see that the Python developer community remains passionate and respectful, and we are sure that the result has benefited a lot because of it.
Congratulations to the PEP(s) authors: Guido, Brandt, Tobias, Daniel, Talin, and everyone that participated in the discussion and implementation of this important new feature!
-The Python Steering Council
I was reading a discussion thread <https://gist.github.com/tiran/2dec9e03c6f901814f6d1e8dad09528e> about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking:
Christian Heimes wrote:
> Core dev and PyPA has spent a lot of effort in promoting venv because we don't want users to break their operating system with sudo pip install.
I don't think sudo pip install should break the operating system. And I think if it does, that problem should be solved rather than merely advising users against using it. And why is it, anyway, that distributions whose package managers can't coexist with pip-installed packages don't ever seem to get the same amount of flak for "damaging python's brand" as Debian is getting from some of the people in the discussion thread? Why is it that this community is resigned to recommending a workaround when distributions decide the site-packages directory belongs to their package manager rather than pip, instead of bringing the same amount of fiery condemnation of that practice as we apparently have for *checks notes* splitting parts of the stdlib into optional packages? Why demand that pip be present if we're not going to demand that it works properly?
I think that installing packages into the actual python installation, both via distribution packaging tools and pip [and using both simultaneously - the Debian model of separated dist-packages and site-packages folders seems like a reasonable solution to this problem] can and should be a supported paradigm, and that virtual environments [or more extreme measures such as shipping an entire python installation as part of an application's deployment] should ideally be reserved for the rare corner cases where that doesn't work for some reason.
How is it that virtual environments have become so indispensable, that no-one considers installing libraries centrally to be a viable model anymore? Are library maintainers making breaking changes too frequently, reasoning that if someone needs the old version they can just venv it? Is there some other cause?