Mailman 3 October 2022 - Python-Dev

PEP 638: Syntactic macros
by Mark Shannon 06 Feb '23

06 Feb '23

Hi everyone, I've submitted my PEP on syntactic macros as PEP 638. https://www.python.org/dev/peps/pep-0638/ All comments and suggestions are welcome. Cheers, Mark

16 25

Switching to Discourse
by Petr Viktorin 26 Jan '23

26 Jan '23

Hello, Currently development discussions are split between multiple communication channels, for example: - python-dev and discuss.python.org for design discussions, - GitHub Issues and Pull Requests for specific changes, - IRC, Discord and private chats for real-time discussions, - Topic-specific channels like typing-sig. While most of these serve different needs, there is too much overlap between python-dev and discuss.python.org. It seems that for most people, this situation is worse than sticking to either one platform – even if we don't go with that person's favorite. The discuss.python.org experiment has been going on for quite a while, and while the platform is not without its issues, we consider it a success. The Core Development category is busier than python-dev. According to staff, discuss.python.org is much easier to moderate.. If you're following python-dev but not discuss.python.org, you're missing out. The Steering Council would like to switch from python-dev to discuss.python.org. Practically, this means: - Moving the required PEP announcements to discuss.python.org - Moving discuss.python.org up in the devguide communications page (https://devguide.python.org/communication/) - And that's it? I imagine that the mailing list will stay around for continuing past discussion threads and for announcements, eventually switching to auto-reject incoming messages with a pointer to discuss.python.org. To be clear, discuss.python.org allows editing posts, which is frankly handy for typos and clarifications. Editing alone should not be used for adding new info -- we should cultivate a culture of being friendly to mail users & notification watchers. This probably bears repeating in a few places. We're aware not everyone wants to use the discuss.python.org website, but there are some ways to avoid it: - For new PEPs, you can point your RSS client to https://www.python.org/dev/peps/peps.rss – it's not e-mail, but many email clients have RSS support. You can also watch the Steering Council issues on GitHub (https://github.com/python/steering-council/issues/) for important questions and discussions. - You can use discuss.python.org's “mailing list mode” (which subscribes you to all new posts), possibly with filtering and/or categorizing messages locally. However, we would like to know if this will pose an undue burden to anyone, if there are workflows or usage problems that we are not aware of. As mentioned, this is something the Steering Council thinks is a good idea, but we want to make sure we're aware of all the impact when we make the final decision. – Petr, on behalf of the Steering Council

43 114

NEWLINE sentinel behavior in CPython's PEG grammar
by David J W 03 Nov '22

03 Nov '22

I am writing a Rust version of Python for fun and I am at the parser stage of development. I copied and modified a PEG grammar ruleset from another open source project and I've already noticed some problems (ex Newline vs NL) with how they transcribed things. I am suspecting that CPython's grammar NEWLINE is a builtin rule for the parser that is something like `(Newline+ | NL+ ) {NOP}` but wanted to sanity check if that is right before I figure out how to hack in a NEWLINE rule and update my grammar ruleset.

5 9

Possible bug in `re` module in Python 3.11?
by Piotr Waszkiewicz 26 Oct '22

26 Oct '22

Hi, I would like to ask your guidance as I'm entirely sure whether the problem I'm experiencing should be posted in CPython's repo as a bug issue. I've tried using newly released Python 3.11 interpreter in some of my projects and one of them failed to start with "RuntimeError: invalid SRE code" error. Looking into implementation of one of the dependencies I've found out that the issue has been found out by a maintainer and fixed (https://github.com/pydicom/pydicom/issues/1658). It looks like this particular regexp caused the `re.compile()` method to raise: ``` re.compile( r"(?P<h>^([01][0-9]|2[0-3]))" r"((?P<m>([0-5][0-9]))?" r"(?(5)(?P<s>([0-5][0-9]|60))?)" r"(?(7)(\.(?P<ms>([0-9]{1,6})?))?))$" ) ``` I've checked and this hasn't been an issue in all previous Python interpreter versions, starting from 3.6 (the oldest I've checked). What's more the regex i correctly recognized and does not cause any issues in other regexp implementations, e.g. the online tool https://regex101.com/ Could somebody help me decide whether this is indeed a bug? Best regards, Piotr Waszkiewicz

3 3

Thank you for your contributions to Python 3.11!
by Pablo Galindo Salgado 26 Oct '22

26 Oct '22

Hi everyone, Now that the 3.11.0 release is finally done and I can relax a bit, I just wanted to thank you all for your fantastic work that has made Python 3.11 such a fantastic release. No matter if you committed code to 3.11 or opened a bug, helped with the documentation, reviewed pull requests, participated in discussions, made a PEP or help writing one, fixed a bug or one hundred or make optimizations to the interpreter or any other of the many ways to contribute. Your work makes a huge difference and Python 3.11 is much better because of that :) Also, I want to especially thank all core devs and contributors that have helped me and the release team take care of release blockers, buildbot failures, CVE patches, and any other form of release crisis. Thank you! Finally, a huge thanks to my colleagues in the release team that make these releases possible and help to make sure that my mistakes are not too obvious to end users :P Being your release manager for 3.11 and 3.10 has been a privilege and an honor (and it will continue for a couple of years of bugfixes and security releases, I'm not going anywhere). Regards from rainy London, Pablo Galindo Salgado

1 0

problem with Distributed File System Replication and Namespacing and different versions of Python 3
by rainonthescarecrowhumanwheels＠gmail.com 26 Oct '22

26 Oct '22

Hi, I have a question about a problem we are facing in different Python versions, like Python 3.7.7, Python 3.8, Python 3.6 and Python 3.9. This apparently doesnt happen in Python 3.10.2 and we were wondering how we could achieve the same behaviours without going deep into the nuts and bolts of the python import system. We have python libraries that are distributed in a networked environment that when imported for the first time they are correctly imported but something happens in the meantime that prevents it from loading anymore. This networked paths are domain paths that are bound to a final "real" path in a specific file server from a specific site in the world. What happens is, when injecting into the sys.path the domain names it doesnt import but when injecting into the sys.path the "real" file server path it works, generally speaking. We have been facing this issue in such different python 3 versions and i was wondering what makes this work in Python 3.10.2. Apparently, in my opinion it is a mix of two things involved: one, something the DFS-R DFS-N does at a very low level, that python 3 versions dont like when importing and the other one, the fact that is a network path. Can anybody shed some light about the improvements regarding this? We will be tied to all these python versions for a very long time and we need to give solution to this. One of the possibilities would be to distribute the libraries into C:/ local disc, this eliminating the network path variable. But it would be nice to know what is causing this in Python < 3.10.2. Thanks in advance.

6 9

Python 3.12.0 alpha 1 released.
by Thomas Wouters 25 Oct '22

25 Oct '22

As Pablo released Python 3.11.0 final earlier today, now it's my turn to release Python 3.12.0 alpha 1. *This is an early developer preview of Python 3.12* Major new features of the 3.12 series, compared to 3.11 Python 3.12 is still in development. This release, 3.12.0a1 is the first of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2023-05-08) and, if necessary, may be modified or deleted up until the release candidate phase (2023-07-31). Please keep in mind that this is a preview release and its use is *not *recommended for production environments. Many new features for Python 3.12 are still being planned and written. Among the new major new features and changes so far: - The deprecated `wstr` and `wstr_length` members of the C implementation of unicode objects were removed, per PEP 623 <https://peps.python.org/pep-0623/>. - In the `unittest` module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2). - The deprecated `smtpd` module has been removed. - A number of other old, broken and deprecated functions, classes and methods have been removed. - (Hey, **fellow core developer,** if a feature you find important is missing from this list, let Thomas know <thomas(a)python.org>.) The next pre-release of Python 3.12 will be 3.12.0a2, currently scheduled for 2022-11-14. More resources - Online Documentation <https://docs.python.org/3.12> - PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the 3.12 Release Schedule - Report bugs at https://github.com/python/cpython/issues. - Help fund Python and its community at https://www.python.org/psf/donations/. And now for something completely different This is Not the Poem that I Had Hoped to Write <https://twitter.com/brian_bilston/status/1579378460610662401> This is not the poem that I had hoped to write when I sat at my desk and the page was white. You see, there were other words that I’d had in mind, yet this is what I leave behind. I thought it was a poem to eradicate war; one of such power, it would heal all the sores of a world torn apart by conflict and schism. But it isn’t. Lovers, I’d imagined, would quote from it daily, Mothers would sing it to soothe crying babies. And whole generations would be given new hope. Nope. I had grand aspirations. Believe me, I tried. Humanity examined with lessons applied. But the right words escaped me; so often they do. Have these in lieu. Brian Bilston <https://twitter.com/brian_bilston> Enjoy the new releases Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. Regards from dusky California, Your release team, Thomas Wouters @Yhg1s Ned Deily @nad Steve Dower @steve.dower -- Thomas Wouters <thomas(a)python.org>

1 0

[RELEASE] Python 3.11 final (3.11.0) is available
by Pablo Galindo Salgado 24 Oct '22

24 Oct '22

Python 3.11 is finally released. In the CPython release team, we have put a lot of effort into making 3.11 the best version of Python possible. Better tracebacks, faster Python, exception groups and except*, typing improvements and much more. Get it here: https://www.python.org/downloads/release/python-3110/ ## This is the stable release of Python 3.11.0 Python 3.11.0 is the newest major release of the Python programming language, and it contains many new features and optimizations. # Major new features of the 3.11 series, compared to 3.10 Some of the new major new features and changes in Python 3.11 are: ## General changes * [PEP 657](https://www.python.org/dev/peps/pep-0657/) -- Include Fine-Grained Error Locations in Tracebacks * [PEP 654](https://www.python.org/dev/peps/pep-0654/) -- Exception Groups and `except*` * [PEP 680](https://www.python.org/dev/peps/pep-0680/) -- tomllib: Support for Parsing TOML in the Standard Library * [gh-90908](https://github.com/python/cpython/issues/90908) -- Introduce task groups to asyncio * [gh-34627](https://github.com/python/cpython/issues/34627/) -- Atomic grouping (`(?>...)`) and possessive quantifiers (`*+, ++, ?+, {m,n}+`) are now supported in regular expressions. * The [Faster CPython Project](https://github.com/faster-cpython/) is already yielding some exciting results. Python 3.11 is up to 10-60% faster than Python 3.10. On average, we measured a 1.22x speedup on the standard benchmark suite. See [Faster CPython]( https://docs.python.org/3.11/whatsnew/3.11.html#faster-cpython) for details. ## Typing and typing language changes * [PEP 673](https://www.python.org/dev/peps/pep-0673/) -- Self Type * [PEP 646](https://www.python.org/dev/peps/pep-0646/) -- Variadic Generics * [PEP 675](https://www.python.org/dev/peps/pep-0675/) -- Arbitrary Literal String Type * [PEP 655](https://www.python.org/dev/peps/pep-0655/) -- Marking individual TypedDict items as required or potentially-missing * [PEP 681](https://www.python.org/dev/peps/pep-0681/) -- Data Class Transforms # More resources * [Online Documentation](https://docs.python.org/3.11/) * [PEP 664](https://www.python.org/dev/peps/pep-0664/), 3.11 Release Schedule * Report bugs at [ https://github.com/python/cpython/issues](https://github.com/python/cpython… . * [Help fund Python and its community](/psf/donations/). # And now for something completely different When a spherical non-rotating body of a critical radius collapses under its own gravitation under general relativity, theory suggests it will collapse to a single point. This is not the case with a rotating black hole (a Kerr black hole). With a fluid rotating body, its distribution of mass is not spherical (it shows an equatorial bulge), and it has angular momentum. Since a point cannot support rotation or angular momentum in classical physics (general relativity being a classical theory), the minimal shape of the singularity that can support these properties is instead a ring with zero thickness but non-zero radius, and this is referred to as a ringularity or Kerr singularity. This kind of singularity has the following peculiar property. The spacetime allows a geodesic curve (describing the movement of observers and photons in spacetime) to pass through the center of this ring singularity. The region beyond permits closed time-like curves. Since the trajectory of observers and particles in general relativity are described by time-like curves, it is possible for observers in this region to return to their past. This interior solution is not likely to be physical and is considered a purely mathematical artefact. There are some other interesting free-fall trajectories. For example, there is a point in the axis of symmetry that has the property that if an observer is below this point, the pull from the singularity will force the observer to pass through the middle of the ring singularity to the region with closed time-like curves and it will experience repulsive gravity that will push it back to the original region, but then it will experience the pull from the singularity again and will repeat this process forever. This is, of course, only if the extreme gravity doesn’t destroy the observer first. # We hope you enjoy the new releases! Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ If you have any questions, please reach out to me or another member of the release team :) Your friendly release team, Ned Deily @nad https://discuss.python.org/u/nad Steve Dower @steve.dower https://discuss.python.org/u/steve.dower Pablo Galindo Salgado @pablogsal https://discuss.python.org/u/pablogsal

1 0

IMPORTANT: Check the 3.11.0 cherry-picks
by Pablo Galindo Salgado 24 Oct '22

24 Oct '22

Hi everyone, I emerged from cherry-picking hell! As mentioned previously, the 3.11.0 final release will be done from the "branch-v3.11.0" branch and will contain a bunch of cherry-picked commits on top of v3.11.0rc2. These commits are: * All documentation commits that **do not touch** any source code (120+ commits). * The following bugfixes: + 6b999982cb8 gh-95027: Fix regrtest stdout encoding on Windows (GH-98492) + 970c10aa6d0 gh-97616: list_resize() checks for integer overflow (GH-97617) + 67f5d24e44c gh-96848: Fix -X int_max_str_digits option parsing (GH-96988) + 9e008fe3519 gh-96821: Fix undefined behaviour in `_testcapimodule.c` (GH-96915) (GH-96927) + bac61bc5b13 gh-95778: Mention sys.set_int_max_str_digits() in error message (GH-96874) + 9cb7324e8fc [3.11] gh-96587: Raise `SyntaxError` for PEP654 on older `feature_version` (GH-96588) (#96591) + 84fd4a54a61 [3.11] gh-97897: Prevent os.mkfifo and os.mknod segfaults with macOS 13 SDK (GH-97944) (#97969) + 1a788914ca6 gh-96865: [Enum] fix Flag to use CONFORM boundary (GH-97528) + c95433573ac [3.11] gh-98331: Update bundled pip to 22.3 (GH-98332) (gh-98400) + fc127628d58 gh-98414: py.exe launcher does not use defaults for -V:company/ option (GH-98460) + 585c95df957 [3.11] GH-97752: Clear the previous member of newly-created generator/coroutine frames (GH-97812) + 4e0fda59f1f gh-98360: multiprocessing now spawns children on Windows with correct argv[0] in virtual environments (GH-98462) + 4c0c1e201a8 [3.11] gh-97514: Don't use Linux abstract sockets for multiprocessing (GH-98501) (GH-98502) + d0ab10f6f01 [3.11] GH-97002: Prevent _PyInterpreterFrames from backing more than one PyFrameObject (GH-98002) + 154b3cd7516 GH-96975: Skip incomplete frames in PyEval_GetFrame (GH-97018) Please *check these commits* and let me know ASAP if we are missing something you would like to include on the 3.11.0 final release. You have until 15:00 UTC+0 today to let me know, otherwise, your changes will need to wait until 3.11.1. Thanks for your help! Regards from sunny London, Pablo Galindo Salgado

1 0

RELEASE MANAGEMENT: Python 3.11 release stream
by Pablo Galindo Salgado 22 Oct '22

22 Oct '22

Hi everyone, I am currently swamped fixing merge conflicts from the cherry-picking to the final release candidate but I wanted to write to tell you I'm excited to confirm that we will be haven a Python 3.11 release party as we did last year with 3.10. The event will be co-hosted by the fantastic people of the Python discord channel. The URL for the stream is this one: https://www.youtube.com/watch?v=PGZPSWZSkJI *The release party will start on October 24th at 17:00 UTC+0.* In this stream, some core developers (Irit, Mark, Brandt, Thomas and Łukasz) will be talking about Python 3.11 features, the work on the faster CPython project, some sneak peek on Python 3.12 and beyond, talking about the core Dev in residence role and other things with some time for moderated Q&A. I will be doing the release live and will also cover what I am doing. Is a fantastic opportunity to watch me break everything live :) Who knows, maybe I break GitHub..... again! :D In the end, people from the audience will be able to ask questions in a moderated Q&A, so it would be fantastic if you can be there to maybe answer some questions from the comments or complete the ones we give (or correct us if we say something wrong). Or you can just hang out quietly. Whatever you prefer is good! The main purpose of the stream is to raise excitement about Python 3.11, explain the new features to users, try to get the community closer to the core Dev team and allow them to ask questions to the core dev team. Also, funny party hats will be used! I hope you find the event interesting and consider attending. Python 3.11 is going to be a fantastic release and we want it to be even better :) Please, reach out to me if you have any questions or suggestions. Regards from rainy London, Pablo Galindo Salgado

1 0

Python-Dev October 2022