🌐 Mailman 3 July 2023 - Python-list - python.org

Canonical list of Python security vulnerabilities
by Bob Kline July 15, 2023

July 15, 2023

Can someone point me to the official catalog of security vulnerabilities in Python (by which I mean cpython and the standard libraries)? I found https://www.cvedetails.com/vulnerability-list/vendor_id-10210/product_id-18… but that isn't maintained by python.org. I also found security-announce(a)python.org, but there hasn't been anything posted there in over a year as far as I can tell, and even before that it's pretty thin. If there's a better place to ask, please advise. Thanks. -- Bob Kline https://www.rksystems.com mailto:bkline@rksystems.com

3 5

Hybrid meeting ANN: Using properties and descriptors
by dn July 11, 2023

July 11, 2023

This month's meeting (Wed 19 July, 1800 for 1830 NZST = 0600/0630 UTC) will cover more-advanced OOP Python skills. You will be most-welcome to join us... "Using properties and descriptors" will look at a series of code-examples exploring problems and how these constructs offer solutions. The presentations are in lecture-style. If there's time (or for later study), some coding workshops will be suggested. Prerequisite knowledge or experience for "Properties": Object-Oriented Programming (in Python), coding custom-classes, using available decorators, some experience in data organisation/design, PEP-008 and coding styles, and reading type-hints. Prerequisite knowledge or experience for "Descriptors": "Properties" topic in this series, coding custom-classes with 'magic methods', implementing inheritance and composition, design-experience in data organisation, Object-Oriented Design, decent understanding of OOP philosophy. Hints: A lab-/log-book will be useful for taking notes. A headset will ease asking questions, answering questions, and discussion. Python IDE ready for coding. Two choices for attendance: online or in-person (Parnell, Auckland). Please RSVP to book-in and receive access information:- - Remote attendance RSVP: https://www.meetup.com/nzpug-auckland/events/njdjssyfckbzb/ - In-person RSVP to https://www.meetup.com/nzpug-auckland/events/294745326/ You are cordially invited to join us! -- Regards, =dn

1 0

[RELEASE] Python 3.12.0 beta 4 released
by Thomas Wouters July 11, 2023

July 11, 2023

Not much time left! I’ve released 3.12.0 beta 4. We’re now in the run-up to rc1, so keep that in mind when you backport to the 3.12 branch. https://www.python.org/downloads/release/python-3120b4/ *This is a beta preview of Python 3.12* Python 3.12 is still in development. This release, 3.12.0b4, is the final of four beta release previews of 3.12. Beta release previews are intended to give the wider community the opportunity to test new features and bug fixes and to prepare their projects to support the new feature release. We *strongly encourage* maintainers of third-party Python projects to *test with 3.12* during the beta phase and report issues found to the Python bug tracker <https://github.com/python/cpython/issues> as soon as possible. While the release is planned to be feature complete entering the beta phase, it is possible that features may be modified or, in rare cases, deleted up until the start of the release candidate phase (Monday, 2023-07-31). Our goal is to have no ABI changes after this release, and as few code changes as possible after 3.12.0rc1, the first release candidate. To achieve that, it will be *extremely important* to get as much exposure for 3.12 as possible during the beta phase. Please keep in mind that this is a preview release and its use is *not *recommended for production environments. *Major new features of the 3.12 series, compared to 3.11* Some of the new major new features and changes in Python 3.12 are: - New type annotation syntax for generic classes (PEP 695 <https://peps.python.org/pep-0695/>). - More flexible f-string parsing, allowing many things previously disallowed (PEP 701 <https://peps.python.org/pep-0701/>). - Support for the buffer protocol in Python code (PEP 688 <https://peps.python.org/pep-0688/>). - Even more improved error messages. More exceptions potentially caused by typos now make suggestions to the user. - Many large and small performance improvements (like PEP 709 <https://peps.python.org/pep-0709/>). - Support for the Linux perf profiler to report Python function names in traces. - 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 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/3.12/whatsnew/3.12.html>. The next pre-release of Python 3.12 will be 3.12.0rc1, the *first release candidate*, currently scheduled for 2023-07-31. *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/>. *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/>. Regards from the alternating thunderstorms and heat waves in Amsterdam, Thomas Wouters. Your release team, Ned Deily Steve Dower Łukasz Langa -- Thomas Wouters <thomas(a)python.org>

1 0

scipy.optimize.least_squares for more than one dimension?
by Martin Schöön July 8, 2023

July 8, 2023

Yesterday I wanted to move from optimize.leastsq to least_squares. I have data depending on four variables and want to fit a function in four variables to this data. This works with leastsq but not with least_squares. Am I trying to do something least_squares is not capable of? Disclaimer: I was burning midnight oil... TIA /Martin

1 1

What is this TEST BANK stuff ?
by Dan Kolis July 6, 2023

July 6, 2023

Why do we tolerate this spam ? this seems most likely a way to inject viruses into people's workflow. That wiped out usenet. Ahh without an explaination; ( and it woudl have to be a good one ); what is the purpsoe of this, why is it here ? Can it be eliminated ? Regards, Dan

5 5

Multiple inheritance and a broken super() chain
by Peter Slížik July 5, 2023

July 5, 2023

Hello. The legacy code I'm working with uses a classic diamond inheritance. Let me call the classes *Top*, *Left*, *Right*, and *Bottom*. This is a trivial textbook example. The classes were written in the pre-super() era, so all of them initialized their parents and Bottom initialized both Left and Right in this order. The result was expected: *Top* was initialized twice: Top.__init__() Left.__init__() Top.__init__() Right.__init__() Bottom.__init__() Now I replaced all parent init calls with *super()*. After this, Top was initialized only once. Top.__init__() Right.__init__() Left.__init__() Bottom.__init__() But at this point, I freaked out. The code is complex and I don't have the time to examine its inner workings. And before, everything worked correctly even though Top was initialized twice. So I decided to break the superclass chain and use super() only in classes inheriting from a single parent. My intent was to keep the original behavior but use super() where possible to make the code more readable. class Top: def __init__(self): print("Top.__init__()") class Left(Top): def __init__(self): super().__init__() print("Left.__init__()") class Right(Top): def __init__(self): super().__init__() print("Right.__init__()") class Bottom(Left, Right): def __init__(self): Left.__init__(self) # Here I'm calling both parents manually Right.__init__(self) print("Bottom.__init__()") b = Bottom() The result has surprised me: Top.__init__() Right.__init__() Left.__init__() Top.__init__() Right.__init__() Bottom.__init__() Now, as I see it, from the super()'s point of view, there are two inheritance chains, one starting at Left and the other at Right. But *Right.__init__()* is called twice. What's going on here? Thanks, Peter

5 9

Best practices for using super()
by Peter Slížik July 5, 2023

July 5, 2023

As a follow-up to my yesterday's question - are there any recommendations on the usage of super()? It's clear that super() can be used to invoke parent's: - instance methods - static methods - constants ("static" attributes in the parent class, e.g. super().NUMBER). This all works, but are there situations in which calling them explicitly using a parent class name is preferred? Best regards, Peter

2 1

Re: Multiple inheritance and a broken super() chain
by Greg Ewing July 5, 2023

July 5, 2023

On 5/07/23 10:33 am, Alan Gauld wrote: > (*) C++ is the odd one out because it doesn't have GC, but then > neither does it have an Object superclass so very often MI in C++ > does not involve creating diamonds! And especially if the MI > style is mixin based. Even if all your mixins have empty constructors, in C++ there is still a diamond problem if they have any data members, because you end up with multiple copies of them. But C++ has the concept of virtual base classes, which avoids the diamond problem, albeit at the expense of making you explicitly call all the base class constructors in your ancestry. -- Greg

2 1

from __future__ import annotations bug?
by Joseph Garvin July 1, 2023

July 1, 2023

``` from __future__ import annotations from typing import Generic, TypeVar T = TypeVar("T") class Foo(Generic[T]): ... class Bar(Foo[Buzz]): ... # NameError here class Buzz: ... ``` This will error, despite the __future__ import, because cpython is trying to look up Buzz before it's defined, even though we have supposedly prevented annotations from being processed. I realize that Class[Args] is allowed in that area in general and isn't always type annotation related, but does this mean that even with PEP 649 that forward references will still be needed?

2 2