🌐 Mailman 3 June 2025 - Python-list - python.org

Searching for a file
by Rob Cliffe Aug. 9, 2025

Aug. 9, 2025

It occurs to me that it might be useful if Python provided a function to search for a file with a given name in various directories (much as the import.import_lib function searches for a module in the directories in sys.path). This function would perhaps be best placed in the os.path or os modules. To start the ball rolling, I offer this version: import sys import os def findfile(fileName, *PathLists): if not PathLists: # Default to searching just sys.path: PathLists = [ sys.path ] # This may or may not be the most useful default; # there is a case for having no default, forcing calls of this function # to explicitly specifiy which paths they want to search, # and perhaps raise an Exception if they don't; # suggestions welcome. for pList in PathLists: # if pList is a str, assume it is a semicolon-separated list of directories # (like the PATH and PYTHONPATH environment variables); # otherwise assume it is a sequence of paths (like sys.path): if isinstance(pList, str): pList = pList.split(';') for path in pList: filePath = os.path.join(path, fileName) if os.path.isfile(filePath): return filePath # Return first match found. # Another possibility is to return a list of all matches. return None Then e.g. print(findfile('os.py')) would print something like C:\Python311\Lib\os.py This idea was partly inspired by Michael Stemper asking about best practice for placing, and finding, a configuration file. Thoughts? Best wishes Rob Cliffe

8 16

configparser get non-existent boolean
by Rob Cliffe July 1, 2025

July 1, 2025

I was surprised to find that in configparser, getboolean() does not raise KeyError for a non-existent config parameter. Demo program (Python 3.11.5, Windows 11): import configparser config = configparser.ConfigParser() config.read('ThisFileDoesNotExist.ini') # This line could be removed MY_BOOL= config['DEFAULT'].getboolean('MY_BOOL') # This does NOT raise an Exception! print(f"{MY_BOOL=}") MY_STR = config['DEFAULT']['MY_STR'] # This does raise an Exception, naturally The output: MY_BOOL=None Traceback (most recent call last): File "R:\Test.py", line 7, in <module> MY_STR = config['DEFAULT']['MY_STR'] # This does raise an Exception, naturally ~~~~~~~~~~~~~~~~~^^^^^^^^^^ File "C:\Python313\Lib\configparser.py", line 1276, in __getitem__ raise KeyError(key) KeyError: 'MY_STR' Is there a good reason for this? Best wishes, Rob Cliffe

2 1

Optimising constant expressions
by Rob Cliffe June 26, 2025

June 26, 2025

I am using Python 3.13.3 on Windows 11. I notice that the compiler can optimise (some) constant expressions containing operators plus numbers or strings, e.g. 2+2 is compiled as 4 1 + (2.5 + 3+4j) is compiled as 6.5+4j 'a' + 'b' is compiled as 'ab' and even 'a'*4096 is compiled as a single long string, but 'a'*4097 isn't (a line must be drawn somewhere). YMMV. This is safe because str, int etc. are built-in types and can not be monkey-patched (at least, not easily; it's beyond my ability 🙂). Question 1: Couldn't this be done with expressions involving *methods* of strings or numbers, e.g. couldn't (15).bit_count() be compiled as 4 'a b c'.split() be compiled as ['a', 'b', 'c'] Is there are reason why this is unsafe? Is it avoided for possible future compatibility issues? Is it too difficult? Would it slow down the compiler too much? Question 2: Couldn't this be done (or is it to some extent already done) with other-built-in types, e.g. couldn't [1] + [2] be compiled as [1,2] Best wishes Rob Cliffe

1 0

Re: Does Python Need Virtual Threads? (Posting On Python-List Prohibited)
by Mild Shock June 25, 2025

June 25, 2025

Concerning virtual threads the only problem with Java I have is, that JDK 17 doesn't have them. And some linux distributions are stuck with JDK 17. Otherwise its not an idea that belongs solely to Java, I think golang pioniered them with their goroutines. I am planning to use them more heavily when they become more widely available, and I don't see any principle objection that Python wouldn't have them as well. It would make async I/O based on async waithing for a thread maybe more lightweight. But this would be only important if you have a high number of tasks. Lawrence D'Oliveiro schrieb: > Short answer: no. > > <https://discuss.python.org/t/add-virtual-threads-to-python/91403> > > Firstly, anybody appealing to Java as an example of how to design a > programming language should immediately be sending your bullshit detector > into the yellow zone. > > Secondly, the link to a critique of JavaScript that dates from 2015, from > before the language acquired its async/await constructs, should be another > warning sign. > > Looking at that Java spec, a “virtual thread” is just another name for > “stackful coroutine”. Because that’s what you get when you take away > implicit thread preemption and substitute explicit preemption instead. > > The continuation concept is useful in its own right. Why not concentrate > on implementing that as a new primitive instead? >

4 8

Runtime detection of PEP 563
by Ian Pilcher June 22, 2025

June 22, 2025

Given a class object (C), is it possible to *reliably* determine whether the class was compiled with PEP 563 (from __future__ import annotations) enabled? Note that simply looking for the presence of C.__module__.annotations is not really reliable. It will fail in the presence of any of these constructs. from __future__ import annotations as ann or from __future__ import annotations del annotations or annotations = some_entirely_unrelated_thing Testing for the presents of C.__module__.annotations will give a false negative in the first two cases and a false positive in the last case. -- ======================================================================== If your user interface is intuitive in retrospect ... it isn't intuitive ========================================================================

1 0

PEP Idea: Extended import syntax for aliasing module attributes
by Omar Ahmed June 18, 2025

June 18, 2025

Hi all, I would like to propose a potential addition to Python's `import` syntax that would improve clarity and ergonomics for cases where developers want both full module access *and* a local alias to a specific attribute within that module. Currently, to get both behaviors, we typically write: import module optimize = module.optimize This works fine, but it is slightly verbose and less explicit in intent. I would like to explore syntax like: import module with module.optimize as optimize or possibly: import module with ( module.optimize as optimize, module.validate as check ) The goal is to import the full module as usual, while simultaneously assigning a local name to a chosen sub-attribute all in a single declaration. This strikes a balance between: *Readability* (makes intensions clearer) *Convenience* (avoids repetitive alias assignments) *Maintainability* (discourages `from module import *`) I am curious to hear whether this type of syntax has been considered before, or if it might be worth formalizing into a PEP. I would be happy to help develop a draft proposal if there is interest. Thank you for reading. -Omar

6 8

Matplotlib "collections" module in recent Python, Matplotlib
by jmhannon.ucdavis＠gmail.com June 18, 2025

June 18, 2025

Greetings. We (the group that I work with) have "inherited" some Python scripts that were written years ago, using Python 2. We're trying to upgrade the scripts so that they work in our current environment: OS: Ubuntu 24.04.2 LTS $ python --version Python 3.11.13 >>> matplotlib.__version__ '3.10.0' The first script that we looked at has a line: cs = plt.contourf(X, Y, data, LevelsNumber, cmap=plt.cm.nipy_spectral, norm=norm).collections If I run that script with python 3, I get a warning: MatplotlibDeprecationWarning: The collections attribute was deprecated in Matplotlib 3.8 and will be removed two minor releases later. cmap=plt.cm.nipy_spectral, norm=norm).collections I also get the following error: paths = cs.get_paths() ^^^^^^^^^^^^ AttributeError: 'list' object has no attribute 'get_paths' The "paths" object that I get appears to be no more than a collection of geometric factors, i.e., without additional attributes such as color, for instance, and statements such as the following fail: bgra_array = 255*paths[i].get_facecolor()[0] AttributeError: 'Path' object has no attribute 'get_facecolor' Unfortunately, all the suggestions that I've found to remedy this suggest using the "collections" attribute, which is already in the code, and which as I noted above, has been deprecated (maybe eliminated -- 3.10 vs. 3.8) now. If you have any suggestions about this, please pass 'em along. Thanks. -- Michael

3 4

Python 3.14.0 beta 3 is here!
by Hugo van Kemenade June 17, 2025

June 17, 2025

It’s 3.14 beta 3! https://www.python.org/downloads/release/python-3140b3/ This is a beta preview of Python 3.14 Python 3.14 is still in development. This release, 3.14.0b3, is the third of four planned beta releases. 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.14 during the beta phase and report issues found to the Python bug tracker 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 (Tuesday 2025-07-22). Our goal is to have no ABI changes after beta 4 and as few code changes as possible after the first release candidate. To achieve that, it will be extremely important to get as much exposure for 3.14 as possible during the beta phase. This includes creating pre-release wheels for 3.14, as it helps other projects to do their own testing. However, we recommend that your regular production releases wait until 3.14.0rc1, to avoid the risk of ABI breaks. 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.14 series, compared to 3.13 Some of the major new features and changes in Python 3.14 are: New features Note that PEPs 734 and 779 are exceptionally new in beta 3! - PEP 779: Free-threaded Python is officially supported - PEP 649: The evaluation of type annotations is now deferred, improving the semantics of using annotations. - PEP 750: Template string literals (t-strings) for custom string processing, using the familiar syntax of f-strings. - PEP 734: Multiple interpreters in the stdlib. - PEP 784: A new module compression.zstd providing support for the Zstandard compression algorithm. - PEP 758: except and except* expressions may now omit the brackets. - Syntax highlighting in PyREPL, and support for color in unittest, argparse, json and calendar CLIs. - PEP 768: A zero-overhead external debugger interface for CPython. - UUID versions 6-8 are now supported by the uuid module, and generation of versions 3-5 and 8 are up to 40% faster. - PEP 765: Disallow return/break/continue that exit a finally block. - PEP 741: An improved C API for configuring Python. - A new type of interpreter. For certain newer compilers, this interpreter provides significantly better performance. Opt-in for now, requires building from source. - Improved error messages. - Builtin implementation of HMAC with formally verified code from the HACL* project. - A new command-line interface to inspect running Python processes using asynchronous tasks. - The pdb module now supports remote attaching to a running Python process. (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) For more details on the changes to Python 3.14, see What’s new in Python 3.14. The next pre-release of Python 3.14 will be the final beta, 3.14.0b4, scheduled for 2025-07-08. https://docs.python.org/3.14/whatsnew/3.14.html Build changes - PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. - Official macOS and Windows release binaries include an experimental JIT compiler. Incompatible changes, removals and new deprecations - Incompatible changes - Python removals and deprecations - C API removals and deprecations - Overview of all pending deprecations Python install manager The installer we offer for Windows is being replaced by our new install manager, which can be installed from the Windows Store or our FTP page. See our documentation for more information. The JSON file available for download below contains the list of all the installable packages available as part of this release, including file URLs and hashes, but is not required to install the latest release. The traditional installer will remain available throughout the 3.14 and 3.15 releases. More resources - [Online documentation](https://docs.python.org/3.14/) - [PEP 745](https://peps.python.org/pep-0745/), 3.14 Release Schedule - Report bugs at [ github.com/python/cpython/issues](https://github.com/python/cpython/issues) - [Help fund Python and its community](https://www.python.org/psf/donations/ ) And now for something completely different If you’re heading out to sea, remember the Maritime Approximation: π mph = e knots https://xkcd.com/3023/ Enjoy the new release 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 organisation contributions to the Python Software Foundation. Regards from sunny Helsinki with 19 hours of daylight, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa

1 0

PythonWin
by wbell＠vex.net June 16, 2025

June 16, 2025

Ahem. Yes, is there a compiled version of this product for 64-bit Python 3.13? (It's still the best IMO.) Or, failing that, anything remotely comparable?

1 0

Re: Seeing Variables
by Mats Wichmann June 12, 2025

June 12, 2025

On 6/12/25 02:59, Stefan Ram wrote: > ram(a)zedat.fu-berlin.de (Stefan Ram) wrote or quoted: >> But how to achieve the same for local variables? > > import pdb > > def f(): > a = 1 > pdb.set_trace() > > f() > > . Now, the program stops there and you can enter: > > print( a ) (user input) > 1 (system output) > > . However, it's a bit more difficult than it could be - > especially for beginners - due to the cryptic names chosen! > One could more easily remember something like: > > import debug > > def f(): > a = 1 > debug.stop() > > f() > > . When a method is named "set_trace", some people might think > its purpose is to set a property called "trace". Moreover, it's > not obvious how invoking an interactive debug session should bring > up the idea of "setting a trace", what does that even mean?? Just use the synonym: breakpoint() That should be pretty clear (a moderatly recent addition - Python 3.7 I think, so about seven years - may not be in every tutorial).

1 0