Mailman 3 - Python-Dev

Retiring this mailing list ?
by Marc-Andre Lemburg 25 Nov '23

25 Nov '23

Hello everyone, for quite a while now, core discussions have moved to Discourse and people are obviously enjoying things there: https://discuss.python.org/c/core-dev/23 The Discourse mailing list mode works reasonably well, so is a suitable replacement for this mailing list. Posts to this list are now mostly spam, mailer error reports and the occasional release postings: https://mail.python.org/archives/list/python-dev@python.org/latest (you can't see much of the spam, since we filter most of it) Question: Should we retire and archive this mailing list ? (I'm asking as one of the maintainers of the ML) Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 13 2023) >>> Python Projects, Coaching and Support ... https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ________________________________________________________________________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/

7 9

Delivery reports about your e-mail
by ethan＠stoneleaf.us 15 Nov '23

15 Nov '23

Your message was not delivered due to the following reason: Your message was not delivered because the destination server was unreachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 5 days: Server 76.93.23.153 is not responding. The following recipients could not receive this message: <python-dev(a)python.org> Please reply to postmaster(a)python.org if you feel this message to be in error.

1 0

HELLO
by mhammond＠skippinet.com.au 14 Nov '23

14 Nov '23

The original message was received at Thu, 5 Oct 2023 09:08:00 +0300 from [87.212.114.230] ----- The following addresses had permanent fatal errors ----- <python-dev(a)python.org> ----- Transcript of session follows ----- ... while talking to python.org.: >>> DATA <<< 400-aturner; %MAIL-E-OPENOUT, error opening !AS as output <<< 400-aturner; -RMS-E-CRE, ACP file create failed <<< 400-aturner; -SYSTEM-F-EXDISKQUOTA, disk quota exceeded <<< 400

1 0

lkmxowjkmf
by theller＠python.net 06 Nov '23

06 Nov '23

The message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message was not delivered within 8 days: Host 39.68.11.75 is not responding. The following recipients did not receive this message: <python-dev(a)python.org> Please reply to postmaster(a)python.net if you feel this message to be in error.

1 0

Proposal: Allow non-default after default arguments
by Sebastian Rittau 16 Oct '23

16 Oct '23

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

detecting statements which result is not stored
by Guenther Sohler 05 Oct '23

05 Oct '23

Hi Python Developers, after some investigation i consider dev the correct mailing list. I got python embedded into OpenSCAD and i'd like to make more use out of it. statements like these do exactly what they should: width= 3*5 solid = make_nice_solid(width) other_solid = solid.size(1) print(" Everything fine") But i'd like to be able to write lines like these: These are expressions which create a value, which is apparently NOT stored in a variable solid *3 other_solid - solid instead of wasting them, I'd like to collect them in an array and display send it to the display engine after python evaluation has finished. Is there some way how i can collect the orphaned expressions ?

2 1

python-dev@python.org
by mhammond＠skippinet.com.au 19 Sep '23

19 Sep '23

The message was undeliverable due to the following reason(s): Your message was not delivered because the destination computer was not reachable within the allowed queue period. The amount of time a message is queued before it is returned depends on local configura- tion parameters. Most likely there is a network problem that prevented delivery, but it is also possible that the computer is turned off, or does not have a mail system running right now. Your message could not be delivered within 1 days: Host 47.86.183.166 is not responding. The following recipients did not receive this message: <python-dev(a)python.org> Please reply to postmaster(a)skippinet.com.au if you feel this message to be in error.

1 0

Message could not be delivered
by fdrake＠acm.org 10 Sep '23

10 Sep '23

The original message was received at Wed, 20 Oct 2021 15:12:36 +0300 from acm.org [25.147.223.204] ----- The following addresses had permanent fatal errors ----- python-dev(a)python.org ----- Transcript of the session follows ----- ... while talking to 146.160.159.171: >>> RCPT To:<python-dev(a)python.org> <<< 550 5.1.1 <python-dev(a)python.org>... Not known here

1 0

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

24 Aug '23

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 06 Aug '23

06 Aug '23

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