Sandbox::https://mail.python.org/archives/list/python-dev@python.org/2023/8/

Proposal: Allow non-default after default arguments
by Sebastian Rittau Oct. 16, 2023

Oct. 16, 2023

Currently, Python doesn't allow non-default arguments after default arguments: >>> def foo(x=None, y): pass File "<stdin>", line 1 def foo(x=None, y): pass ^ SyntaxError: non-default argument follows default argument I believe that at the time this was introduced, no use cases for this were known and this is is supposed to prevent a source of bugs. I have two use cases for this, one fringe, but valid, the other more important: The fringe use case: Suppose you have a function that takes a 2D coordinate value as separate "x" and "y" arguments. The "x" argument is optional, the "y" argument isn't. Currently there are two ways to do this, none of them particularly great: def foo(y, x): # reverse x and y arguments, confusing ... def foo(x, y=None): # Treat the x argument as y if only one argument is provided if y is None: x, y = y, x ... To me, the "natural" solution looks like this: def foo(x=None, y): ... # Called like this: foo(1, 2) foo(y=2) This could also be useful when evolving APIs. For example there is a function "bar" that takes two required arguments. In a later version, the first argument gains a useful default, the second doesn't. There is no sensible way to evolve the API at the moment. The more important use case involves @overloads. A condensed example of a function where the return type depends on an "encoding" parameter, followed by further parameters that could be called like this: foo(123, "utf-8") # would return bytes foo(encoding="utf-8") foo(123, None) # would return str foo(encoding=None) foo(x=123) # would return str foo() This could ideally be written as: @overload def foo(x: int = ..., encoding: None = ...) -> str: ... @overload def foo(x: int = ..., encoding: str) -> bytes: ... # plus the actual implementation But due to the syntax constraint, this needs to be hacked around with a third overload: @overload def foo(x: int = ... encoding: None = ...) -> str: ... @overload def foo(x: int, encoding: str) -> bytes: ... # for foo(123, "utf-8") @overload def foo(*, encoding: str) -> bytes: ... # for foo(encoding="utf-8") Not only is this hard to read, real examples in typeshed are usually more complex, with many arguments before or after the affected argument or even multiple affected arguments. This often becomes too complex to write or maintain. Here is one example from the wild: https://github.com/python/typeshed/blob/b95b729b9e07ab21d252701af0f5b740467… Allowing non-default arguments after default arguments would solve both use cases above and eliminates a special case. I'm also not sure what exactly the current SyntaxError really protects us from. Adding a non-default after a default argument can't really lead bugs. - Sebastian

11 14

[RELEASE] Python 3.11.5, 3.10.13, 3.9.18, and 3.8.18 is now available
by Łukasz Langa Aug. 24, 2023

Aug. 24, 2023

There’s security content in the releases, let’s dive right in. gh-108310 <https://github.com/python/cpython/issues/108310>: Fixed an issue where instances of ssl.SSLSocket <https://docs.python.org/release/3.10.13/library/ssl.html#ssl.SSLSocket> were vulnerable to a bypass of the TLS handshake and included protections (like certificate verification) and treating sent unencrypted data as if it were post-handshake TLS encrypted data. Security issue reported as CVE-2023-40217 1 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-40217> by Aapo Oksman. Patch by Gregory P. Smith. Upgrading is highly recommended to all users of affected versions. <https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.11.5 Get it here: https://www.python.org/downloads/release/python-3115/ This release was held up somewhat by the resolution of this CVE, which is why it includes a whopping 328 new commits since 3.11.4 (compared to 238 commits between 3.10.4 and 3.10.5). Among those, there is a fix for CVE-2023-41105 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-41105>which affected Python 3.11.0 - 3.11.4. See gh-106242 <https://github.com/python/cpython/issues/106242> for details. There are also some fixes for crashes, check out the change log <https://docs.python.org/release/3.11.5/whatsnew/changelog.html> to see all information. Most importantly, the release notes on the downloads page <https://www.python.org/downloads/release/python-3115/> include a description of the Larmor precession. I understood some of the words there! <https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.10.13 Get it here: https://www.python.org/downloads/release/python-31013/ 16 commits. <https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.9.18 Get it here: https://www.python.org/downloads/release/python-3918/ 11 commits. <https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Python 3.8.18 Get it here: https://www.python.org/downloads/release/python-3818/ 9 commits. <https://discuss.python.org/t/python-3-11-5-3-10-13-3-9-18-and-3-8-18-is-now…>Stay safe and upgrade! 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. -- Łukasz Langa @ambv <https://discuss.python.org/u/ambv> on behalf of 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> Łukasz Langa @ambv <https://discuss.python.org/u/ambv> Thomas Wouters @thomas <https://discuss.python.org/u/thomas>

1 0

[RELEASE] Python 3.12.0 release candidate 1 released
by Thomas Wouters Aug. 6, 2023

Aug. 6, 2023

I'm pleased to announce the release of Python 3.12.0rc1: https://www.python.org/downloads/release/python-3120rc1/ This is the first release candidate of Python 3.12.0 This release, *3.12.0rc1*, is the penultimate release preview. Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release. The second candidate (and the last planned release preview) is scheduled for Monday, 2023-09-04, while the official release of 3.12.0 is scheduled for Monday, 2023-10-02. There will be *no ABI changes* from this point forward in the 3.12 series, and the goal is that there will be as few code changes as possible. <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Call to action We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.12 compatibilities during this phase, and where necessary publish Python 3.12 wheels on PyPI to be ready for the final release of 3.12.0. Any binary wheels built against Python 3.12.0rc1 will work with future versions of Python 3.12. As always, report any issues to the Python bug tracker <https://github.com/python/cpython/issues>. Please keep in mind that this is a preview release and while it’s as close to the final release as we can get it, its use is *not* recommended for production environments. <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Core developers: time to work on documentation now - Are all your changes properly documented? - Are they mentioned in What’s New <https://docs.python.org/3.12/whatsnew/3.12.html>? - Did you notice other changes you know of to have insufficient documentation? <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Major new features of the 3.12 series, compared to 3.11 <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>New features - More flexible f-string parsing <https://docs.python.org/3.12/whatsnew/3.12.html#pep-701-syntactic-formaliza…>, allowing many things previously disallowed (PEP 701 <https://peps.python.org/pep-0701/>). - Support for the buffer protocol <https://docs.python.org/3.12/whatsnew/3.12.html#pep-688-making-the-buffer-p…> in Python code (PEP 688 <https://peps.python.org/pep-0688/>). - A new debugging/profiling API (PEP 669 <https://peps.python.org/pep-0669/>). - Support for isolated subinterpreters <https://docs.python.org/3.12/whatsnew/3.12.html#pep-684-a-per-interpreter-g…> with separate Global Interpreter Locks (PEP 684 <https://peps.python.org/pep-0684>). - Even more improved error messages <https://docs.python.org/3.12/whatsnew/3.12.html#improved-error-messages>. More exceptions potentially caused by typos now make suggestions to the user. - Support for the Linux perf profiler <https://docs.python.org/3.12/howto/perf_profiling.html> to report Python function names in traces. - Many large and small performance improvements <https://docs.python.org/3.12/whatsnew/3.12.html#optimizations> (like PEP 709 <https://peps.python.org/pep-0709/>), delivering an estimated 5% overall performance improvementcitation needed. <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>Type annotations - New type annotation syntax <https://docs.python.org/3.12/whatsnew/3.12.html#pep-695-type-parameter-synt…> for generic classes (PEP 695 <https://peps.python.org/pep-0695/>). - New override decorator <https://docs.python.org/3.12/whatsnew/3.12.html#pep-698-override-decorator-…> for methods (PEP 698 <https://peps.python.org/pep-0698>). <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…> Deprecations - 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 and distutils modules have been removed (see PEP 594 <https://peps.python.org/pep-0594/> and PEP 632 <https://peps.python.org/pep-0632/>. The setuptools package continues to provide the distutils module. - A number of other old, broken and deprecated functions, classes and methods <https://docs.python.org/3.12/whatsnew/3.12.html#removed> have been removed. - Invalid backslash escape sequences in strings now warn with SyntaxWarning instead of DeprecationWarning, making them more visible. (They will become syntax errors in the future.) - The internal representation of integers has changed in preparation for performance enhancements. (This should not affect most users as it is an internal detail, but it may cause problems for Cython-generated code.) (Hey, *fellow core developer,* if a feature you find important is missing from this list, let Thomas know <thomas(a)python.org>.) For more details on the changes to Python 3.12, see What’s new in Python 3.12 <https://docs.python.org/dev/whatsnew/3.12.html>. The next pre-release of Python 3.12 will be 3.12.0rc2, the *final release candidate*, currently scheduled for 2023-09-04. <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>More resources - Online Documentation <https://docs.python.org/3.12/>. - PEP 693 <https://www.python.org/dev/peps/pep-0693/>, the Python 3.12 Release Schedule. - Report bugs via GitHub Issues <https://github.com/python/cpython/issues>. - Help fund Python and its community <https://www.python.org/psf/donations/>. <https://discuss.python.org/t/python-3-12-0-release-candidate-1-released/311…>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-landing/>. Your release team, Thomas Wouters Ned Deily Steve Dower Łukasz Langa -- Thomas Wouters <thomas(a)python.org>

1 0

Some pattern annoyance
by Christian Tismer-Sperling Aug. 3, 2023

Aug. 3, 2023

Hi folks, I just used Structural Pattern Matching quite intensively and I'm pretty amazed of the new possibilities. But see this code, trying to implement Mark Pilgrim's regex algorithm for roman literals with SPM: With constants, I can write match seq: case "M", "M", "M", "M", *r: return 4 * 1000, r But if I want to use abbreviations by assignment, this is no longer possible, and I have to write something weird like: M = "M" match seq: case a, b, c, d, *r if M == a == b == c == d: return 4 * 1000, r So what is missing seems to be a notion of const-ness, which could be dynamically deduced. Am I missing something? -- Christian Tismer-Sperling :^) tismer(a)stackless.com Software Consulting : http://www.stackless.com/ Strandstraße 37 : https://github.com/PySide 24217 Schönberg : GPG key -> 0xFB7BEE0E phone +49 173 24 18 776 fax +49 (30) 700143-0023

5 7

Python-Dev

August 2023