Assignment of global variables in a script.
Dear Sirs. I found the following sentence in the Python documentation: "The statements executed by the top-level invocation of the interpreter, either read from a script file or interactively, are considered part of a module called __main__<https://docs.python.org/3.11/library/__main__.html#module-__main__>, so they have their own global namespace." In other words, global assignments of variables placed directly in a module's name space are also "statements executed by the top-level invocation of the interpreter", if the module is executed as a script. Is it stable at all to assign global variables directly in a module which runs as a script? Speaking practically, I have not observed any problem so far. Regards, Dmitry Popov -- https://mail.python.org/mailman3//lists/python-list.python.org
configparser get non-existent boolean
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
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
--
https://mail.python.org/mailman3//lists/python-list.python.org
Optimising constant expressions
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 -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: What does stats = await asyncio.to_thread(os.stat, url) do? (Was async I/O via threads is extremly slow)
Other languages uses thread pool, instead of creating new thread. In Python,loop.run_in_executor uses thread pool. https://docs.python.org/3.13/library/asyncio-eventloop.html#asyncio.loop.run_in_executor 2025年6月24日(火) 8:12 Mild Shock : > > So what does: > > stats = await asyncio.to_thread(os.stat, url) > > Whell it calls in a sparate new secondary thread: > > os.stat(url) > > It happends that url is only a file path, and > the file path points to an existing file. So the > secondary thread computs the stats, and terminates, > > and the async framework hands the stats back to > the main thread that did the await, and the main > thread stops his waiting and continues to run > > cooperatively with the other tasks in the current > event loop. The test case measures the wall time. > The results are: > > > node.js: 10 ms (usual Promises and stuff) > > JDK 24: 50 ms (using Threads, not yet VirtualThreads) > > pypy: 2000 ms > > I am only using one main task, sequentially on > such await calles, with a couple of file, not > more than 50 files. > > I could compare with removing the async detour, > to qualify the async I/O detour overhead. > > Mild Shock schrieb: > > Hi, > > > > async I/O in Python is extremly disappointing > > and an annoying bottleneck. > > > > The problem is async I/O via threads is currently > > extremly slow. I use a custom async I/O file property > > predicate. It doesn't need to be async for file > > > > system access. But by some historical circumstances > > I made it async since the same file property routine > > might also do a http HEAD request. But what I was > > > > testing and comparing was a simple file system access > > inside a wrapped thread, that is async awaited. > > Such a thread is called for a couple of directory > > > > entries to check a directory tree whether updates > > are need. Here some measurement doing this simple > > involving some little async I/O: > > > > node.js: 10 ms (usual Promises and stuff) > > JDK 24: 50 ms (using Threads, not yet VirtualThreads) > > pypy: 2000 ms > > > > So currently PyPy is 200x times slower than node.js > > when it comes to async I/O. No files were read or > > written in the test case, only "mtime" was read, > > > > via this Python line: > > > > stats = await asyncio.to_thread(os.stat, url) > > > > Bye > > > > Mild Shock schrieb: > >> > >> 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? > >>> > >> > > > -- > https://mail.python.org/mailman3//lists/python-list.python.org -- Inada Naoki -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: async I/O via threads is extremly slow (Was: Does Python Need Virtual Threads?)
I honestly have no idea what's being measured, but here are some numbers to compare this to, and then some explanation about async I/O in general. 1. No I/O to a local disk on a modern controller should take milliseconds. The time you are aiming for is below millisecond. That is, writing a block to disk should take less than a millisecond. 2. Linux and some other operating systems have an ability to work asynchronously with network I/O through calls from the epoll family (the story of these system calls is ironic due to how many iterations of failures resulted in what we have today, and then was abandoned in favor of io_uring anyways). I/O to disk, unless you are using io_uring is never asynchronous. Using threads may help *other* code to run asynchronously, but I/O inside threads is still blocking. I have no idea what stats = await asyncio.to_thread(os.stat, url) may be doing. But, looking at these stats: https://en.wikipedia.org/wiki/IOPS, 2 seconds should be enough, on a modern server to write... a lot of data. Let's be modest and assume you are using an Intel SSD with 5K IOPS, then you should be able to write 320 MiB in this time, unless I miscounted the zeroes :D In general though... I think that the subject of threads and I/O are orthogonal and trying to come up with any sort of metric to measure both at the same time somehow... is just not going to give you any sensible description of the situation. So... maybe rethink the problem? Maybe eliminate threads from the equation? Also... I have no idea why Python needs async/await. It's a very confusing and unwieldy interface to epoll. I never found a practical reason to use this, unless in the situation where someone else used this in their library, and I had to use the library. All in all, it's better to pretend this part of Python doesn't exist. It's pointless and poorly written on top of that. On Mon, Jun 23, 2025 at 9:42 PM Mild Shock wrote: > > Hi, > > async I/O in Python is extremly disappointing > and an annoying bottleneck. > > The problem is async I/O via threads is currently > extremly slow. I use a custom async I/O file property > predicate. It doesn't need to be async for file > > system access. But by some historical circumstances > I made it async since the same file property routine > might also do a http HEAD request. But what I was > > testing and comparing was a simple file system access > inside a wrapped thread, that is async awaited. > Such a thread is called for a couple of directory > > entries to check a directory tree whether updates > are need. Here some measurement doing this simple > involving some little async I/O: > > node.js: 10 ms (usual Promises and stuff) > JDK 24: 50 ms (using Threads, not yet VirtualThreads) > pypy: 2000 ms > > So currently PyPy is 200x times slower than node.js > when it comes to async I/O. No files were read or > written in the test case, only "mtime" was read, > > via this Python line: > > stats = await asyncio.to_thread(os.stat, url) > > Bye > > Mild Shock schrieb: > > > > 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? > >> > > > -- > https://mail.python.org/mailman3//lists/python-list.python.org -- https://mail.python.org/mailman3//lists/python-list.python.org
Runtime detection of PEP 563
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 -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
The solution was provided in this thread here: https://discuss.python.org/t/extended-import-syntax-for-aliasing-module-attributes/95920/3 The correct way to implement is: import module from module import optimize, validate as check -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
Thank you. I have used this link. I had difficulty finding it. https://discuss.python.org/ -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
Thank you. I have posted this idea on https://discuss.python.org/c/ideas/6 I had difficulty trying to find that. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Matplotlib "collections" module in recent Python, Matplotlib
Thanks, D'Arcy. I've done a fair amount of 2-to-3 migration in the past, but
there was a lot of stuff in that article ("six", for instance) that I hadn't
run across.
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Matplotlib "collections" module in recent Python, Matplotlib
Thanks. That appears to be exactly the thing I was looking for (vis-a-vis collections). -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
And here: https://discuss.python.org/c/ideas/6 Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://compileralchemy.substack.com/> github <https://github.com/Abdur-RahmaanJ> Mauritius On Tue, Jun 17, 2025 at 4:20 PM Barry Scott wrote: > > > > On 17 Jun 2025, at 00:19, Omar Ahmed via Python-list < > python-list@python.org> wrote: > > > > 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. > > > > FYI python idea are discussed on https://discussion.fedoraproject.org/ > these days. > You will get a lot of feedback there. > > Barry > > > -- > https://mail.python.org/mailman3//lists/python-list.python.org > -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
On Tue, Jun 17, 2025 at 8:19 AM Barry Scott wrote: > > > > On 17 Jun 2025, at 00:19, Omar Ahmed via Python-list < > python-list@python.org> wrote: > > > > 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. > > > > FYI python idea are discussed on https://discussion.fedoraproject.org/ > these days. > You will get a lot of feedback there. > > Barry > > Are you sure you meant to point to the Fedora discussion, not python? -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: PEP Idea: Extended import syntax for aliasing module attributes
On 17/06/2025 00:19, Omar Ahmed via Python-list wrote: 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 If the only module attrributes you want are the ones you list explicitly, you can already write from module import ( optimize, validate as check ) Explicit, convenient, readable and less verbose! Of course if you do this, you will get a NameError if you subsequently do module.someOtherAttribute or even just module So this may or may not meet your use case. If it does, it is arguably an advantage that your namespace is not cluttered by having "module" in it You have explicitly documented which attributes of "module" your code uses, and will get an error if you try to use a different one without listing it. If not, you can just add import module (slightly clunky in that you now have 2 import statements referring to the same module, but as I understand it will not be significantly slower - the module will only be imported once). Best wishes, Rob Cliffe -- https://mail.python.org/mailman3//lists/python-list.python.org
PEP Idea: Extended import syntax for aliasing module attributes
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 -- https://mail.python.org/mailman3//lists/python-list.python.org
Matplotlib "collections" module in recent Python, Matplotlib
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
--
https://mail.python.org/mailman3//lists/python-list.python.org
Feedback & Discussion: Magic Wormhole 0.19.0 Release Updates
Hi everyone, I just read the release announcement for Magic Wormhole 0.19.0, and I wanted to start a thread here to appreciate the work and open up discussion for anyone using or interested in it. Some exciting highlights: New status feedback API, finally, some clean visibility into code consumption Better reconnection handling via Dilation timeouts pytest test suite conversion Python 3.9 support dropped (good call in line with ecosystem trends) sdist file renaming (PEP 625 compliance) These seem like solid improvements for both the end-user experience and contributors. Has anyone here already tried out the new version in their workflow? Any performance or UX changes you've noticed? Also, curious if anyone has used the lower-level protocol (beyond file transfers) in a real project, would love to hear about that. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: magic-wormhole 0.19.0
Thanks for sharing the update, Meejah! Great to see the addition of the status feedback API and improved Dilation handling, those changes should definitely enhance usability and performance. Also appreciate the move to pytest and the clearer packaging per PEP 625. Solid work! -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python tutor mailing list?
Being a user of that list i've also noticed that only recently. hope that this list is good enough to take on all python questions. Are there any other alternative lists? Thx On Wed, 28 May 2025, 01:35 Alan Gauld via Python-list, < python-list@python.org> wrote: > I am the moderator of the python tutor mailing list. > Or at least I was. It seems the tutor list has been deleted. > I came back from vacation to find that I can't access it. > > Nobody told me anything in advance. I've tried emailing > postmaster but got no response. > > I wonder if anyone here has any idea of what happened and why? > The list had quietened down a lot since its heyday but > there were still a few messages per month going to it. > > The archives are still there and the sign-up page seems to > work, but it doesn't recognise me. I tried signing up as > a new member with a different address and that seems to work(ie no > errors) but I still don;t see any list activity. > > So, is it just the case that the admins have unsubscribed > everyone on the list (again, this happened a few years ago)? > > Puzzled, > -- > Alan G > Author of the Learn to Program web site > http://www.alan-g.me.uk/ > http://www.amazon.com/author/alan_gauld > Follow my photo-blog on Flickr at: > http://www.flickr.com/photos/alangauldphotos > > -- > https://mail.python.org/mailman3//lists/python-list.python.org > -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Searching for a file
ke 28.5.2025 klo 1.45 Thomas Passin (li...@tompassin.net) kirjoitti:
> On 5/27/2025 10:41 AM, Roland Mueller via Python-list wrote:
> > To get a list of files in a given directory one can use glob.glob and
>
> The OP had a different problem. He wanted to find a config file of
> known name that could be in one of several locations.
>
This can be done by replacing the star wildcard the join(dir, '*') with a
filename or filename glob pattern.
>>> tmp_files = []
>>> for dir in ['/tmp', '/var/tmp']:
... tmp_files += [f for f in glob(join(dir, filename_to_find)) if
isfile(f) ]
>
> > os.path.isfile
> >
> >>>> from os.path import isfile
> >>>> from glob import glob
> >>>> files_in_var_tmp = [f for f in glob('/var/tmp/*') if isfile(f) ]
> >
> > For several directories iterate over the dirs and add the resulting list
> of
> > files.
> >
> >>>> tmp_files = []
> >>>> for dir in ['/tmp', '/var/tmp']:
> > ... tmp_files += [f for f in glob(dir + '/*') if isfile(f) ]
> >
> >
> > ti 27.5.2025 klo 17.05 Peter J. Holzer (hjp-pyt...@hjp.at) kirjoitti:
> >
> >> On 2025-05-24 17:18:11 -0600, Mats Wichmann wrote:
> >>> On 5/23/25 16:05, Rob Cliffe via Python-list wrote:
> >>>> On 23/05/2025 18:55, Mats Wichmann wrote:
> >>>>> On 5/22/25 21:04, Rob Cliffe via Python-list wrote:
> >>>>>> 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:
> >>>>> consider: os.walk, glob.glob, Path.glob
> >>>>>
> >>>>>
> >>>> I have. None of these are appropriate.
> >>>> os.walk iterates *recursively* over a *single* directory and its
> >>>> subdirectories.
> >>>> pathlib.Path.glob so far as I can make out (I have never used pathlib)
> >>>> does much the same.
> >>>> glob.glob (so far as I can make out) does a *wildcard* search for
> >>>> directories matching a *single* pattern.
> >>>> My suggestion needs a *non-recursive* search for a *file* in a *list*
> >> of
> >>>> *non-wildcarded* directories.
> >>>
> >>> They don't give you "search in a list of directories" intrinsically,
> but
> >>> that's simple loop, bailing out on a match, no?
> >>
> >> But they all read directories. For Rob's purpose this isn't necessary.
> >> He just needs to test a fixed number of locations. Reading even one
> >> directory (muss less recursively scanning a whole tree like os.walk
> >> does) is just pointless extra work.
> >>
> >> hjp
> >>
> >> --
> >> _ | Peter J. Holzer| Story must make more sense than reality.
> >> |_|_) ||
> >> | | | h...@hjp.at |-- Charles Stross, "Creative writing
> >> __/ | http://www.hjp.at/ | challenge!"
> >> --
> >> https://mail.python.org/mailman3//lists/python-list.python.org
> >>
>
> --
> https://mail.python.org/mailman3//lists/python-list.python.org
>
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python tutor mailing list?
Message received! Hope you enjoyed your holiday... On 28/05/25 12:00, Alan Gauld via Python-list wrote: On 28/05/2025 00:32, Alan Gauld via Python-list wrote: The archives are still there and the sign-up page seems to work, but it doesn't recognise me. I tried signing up as a new member with a different address and that seems to work(ie no errors) but I still don;t see any list activity. I sent a test message and it sent a response saying my message was in a queue waiting for the moderator. But since that's me and it won't let me in, I can't approve anything, So I assume there will be a bunch of stuff just sitting in a queue waiting for a non-existent moderator. I guess this proves the list is still there in some form! Back to the postmaster to see how I get this fixed... I do notice we seem to have moved to Mailman3 as a server, perhaps it has something to do with the migration? It would have been nice to be told though. -- Regards, =dn -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Python tutor mailing list?
On 28/05/2025 00:32, Alan Gauld via Python-list wrote: > The archives are still there and the sign-up page seems to > work, but it doesn't recognise me. I tried signing up as > a new member with a different address and that seems to work(ie no > errors) but I still don;t see any list activity. I sent a test message and it sent a response saying my message was in a queue waiting for the moderator. But since that's me and it won't let me in, I can't approve anything, So I assume there will be a bunch of stuff just sitting in a queue waiting for a non-existent moderator. I guess this proves the list is still there in some form! Back to the postmaster to see how I get this fixed... I do notice we seem to have moved to Mailman3 as a server, perhaps it has something to do with the migration? It would have been nice to be told though. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman3//lists/python-list.python.org
Python tutor mailing list?
I am the moderator of the python tutor mailing list. Or at least I was. It seems the tutor list has been deleted. I came back from vacation to find that I can't access it. Nobody told me anything in advance. I've tried emailing postmaster but got no response. I wonder if anyone here has any idea of what happened and why? The list had quietened down a lot since its heyday but there were still a few messages per month going to it. The archives are still there and the sign-up page seems to work, but it doesn't recognise me. I tried signing up as a new member with a different address and that seems to work(ie no errors) but I still don;t see any list activity. So, is it just the case that the admins have unsubscribed everyone on the list (again, this happened a few years ago)? Puzzled, -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Searching for a file
When answering I saw only the post from Peter. Everything else was in SPAM
folder. GMail was so kind to move the "junk" mails to my Inbox after
pressing SENT :-)
My code works in Linux but with a small change it should work in Windows
too.
ti 27.5.2025 klo 17.41 Roland Mueller (roland.em0...@googlemail.com)
kirjoitti:
> To get a list of files in a given directory one can use glob.glob and
> os.path.isfile
>
> >>> from os.path import isfile
> >>> from glob import glob
> >>> files_in_var_tmp = [f for f in glob('/var/tmp/*') if isfile(f) ]
>
> For several directories iterate over the dirs and add the resulting list
> of files.
>
> >>> tmp_files = []
> >>> for dir in ['/tmp', '/var/tmp']:
> ... tmp_files += [f for f in glob(dir + '/*') if isfile(f) ]
>
>>> from os.path import isfile, join
>>> from glob import glob
>>> tmp_files = []
>>> for dir in ['/tmp', '/var/tmp']:
... tmp_files += [f for f in glob(join(dir, '*')) if isfile(f) ]
Here os.path.join is used to put the parts for the glob mask together
instead of plain '/'.
>
>
> ti 27.5.2025 klo 17.05 Peter J. Holzer (hjp-pyt...@hjp.at) kirjoitti:
>
>> On 2025-05-24 17:18:11 -0600, Mats Wichmann wrote:
>> > On 5/23/25 16:05, Rob Cliffe via Python-list wrote:
>> > > On 23/05/2025 18:55, Mats Wichmann wrote:
>> > > > On 5/22/25 21:04, Rob Cliffe via Python-list wrote:
>> > > > > 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:
>> > > > consider: os.walk, glob.glob, Path.glob
>> > > >
>> > > >
>> > > I have. None of these are appropriate.
>> > > os.walk iterates *recursively* over a *single* directory and its
>> > > subdirectories.
>> > > pathlib.Path.glob so far as I can make out (I have never used pathlib)
>> > > does much the same.
>> > > glob.glob (so far as I can make out) does a *wildcard* search for
>> > > directories matching a *single* pattern.
>> > > My suggestion needs a *non-recursive* search for a *file* in a *list*
>> of
>> > > *non-wildcarded* directories.
>> >
>> > They don't give you "search in a list of directories" intrinsically, but
>> > that's simple loop, bailing out on a match, no?
>>
>> But they all read directories. For Rob's purpose this isn't necessary.
>> He just needs to test a fixed number of locations. Reading even one
>> directory (muss less recursively scanning a whole tree like os.walk
>> does) is just pointless extra work.
>>
>> hjp
>>
>> --
>>_ | Peter J. Holzer| Story must make more sense than reality.
>> |_|_) ||
>> | | | h...@hjp.at |-- Charles Stross, "Creative writing
>> __/ | http://www.hjp.at/ | challenge!"
>> --
>> https://mail.python.org/mailman3//lists/python-list.python.org
>>
>
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Searching for a file
To get a list of files in a given directory one can use glob.glob and
os.path.isfile
>>> from os.path import isfile
>>> from glob import glob
>>> files_in_var_tmp = [f for f in glob('/var/tmp/*') if isfile(f) ]
For several directories iterate over the dirs and add the resulting list of
files.
>>> tmp_files = []
>>> for dir in ['/tmp', '/var/tmp']:
... tmp_files += [f for f in glob(dir + '/*') if isfile(f) ]
ti 27.5.2025 klo 17.05 Peter J. Holzer (hjp-pyt...@hjp.at) kirjoitti:
> On 2025-05-24 17:18:11 -0600, Mats Wichmann wrote:
> > On 5/23/25 16:05, Rob Cliffe via Python-list wrote:
> > > On 23/05/2025 18:55, Mats Wichmann wrote:
> > > > On 5/22/25 21:04, Rob Cliffe via Python-list wrote:
> > > > > 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:
> > > > consider: os.walk, glob.glob, Path.glob
> > > >
> > > >
> > > I have. None of these are appropriate.
> > > os.walk iterates *recursively* over a *single* directory and its
> > > subdirectories.
> > > pathlib.Path.glob so far as I can make out (I have never used pathlib)
> > > does much the same.
> > > glob.glob (so far as I can make out) does a *wildcard* search for
> > > directories matching a *single* pattern.
> > > My suggestion needs a *non-recursive* search for a *file* in a *list*
> of
> > > *non-wildcarded* directories.
> >
> > They don't give you "search in a list of directories" intrinsically, but
> > that's simple loop, bailing out on a match, no?
>
> But they all read directories. For Rob's purpose this isn't necessary.
> He just needs to test a fixed number of locations. Reading even one
> directory (muss less recursively scanning a whole tree like os.walk
> does) is just pointless extra work.
>
> hjp
>
> --
>_ | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | | | h...@hjp.at |-- Charles Stross, "Creative writing
> __/ | http://www.hjp.at/ | challenge!"
> --
> https://mail.python.org/mailman3//lists/python-list.python.org
>
--
https://mail.python.org/mailman3//lists/python-list.python.org
Python 3.14.0 beta 2 is here!
Here’s the second 3.14 beta. https://www.python.org/downloads/release/python-3140b2/ This is a beta preview of Python 3.14 Python 3.14 is still in development. This release, 3.14.0b2, is the second 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 - 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 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 3.14.0b3, scheduled for 2025-06-17. 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. 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, 3.14 Release Schedule: https://peps.python.org/pep-0745/ - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different In 1897, the State of Indiana almost passed a bill defining π as 3.2. Of course, it’s not that simple. Edwin J. Goodwin, M.D., claimed to have come up with a solution to an ancient geometrical problem called squaring the circle, first proposed in Greek mathematics. It involves trying to draw a circle and a square with the same area, using only a compass and a straight edge. It turns out to be impossible because π is transcendental (and this had been proved just 13 years earlier by Ferdinand von Lindemann), but Goodwin fudged things so the value of π was 3.2 (his writings have included at least nine different values of π: including 4, 3.236, 3.232, 3.2325… and even 9.2376…). Goodwin had copyrighted his proof and offered it to the State of Indiana to use in their educational textbooks without paying royalties, provided they endorsed it
Re: Searching for a file
On Sun, 25 May 2025 at 10:05, Rob Cliffe via Python-list wrote: > Yes, but if I understand correctly, they all start from a single > directory (and work downwards if required). > My suggestion involved searching a *list* (possibly multiple lists) of > directories. for dir in dirs: try: open(dir + "/" + fn).close() except FileNotFoundError: pass else: break Is this really all that difficult? Not everything has to be in the stdlib. ChrisA -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Searching for a file
On 25/05/2025 00:18, Mats Wichmann wrote: On 5/23/25 16:05, Rob Cliffe via Python-list wrote: On 23/05/2025 18:55, Mats Wichmann wrote: On 5/22/25 21:04, Rob Cliffe via Python-list wrote: 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: consider: os.walk, glob.glob, Path.glob I have. None of these are appropriate. os.walk iterates *recursively* over a *single* directory and its subdirectories. pathlib.Path.glob so far as I can make out (I have never used pathlib) does much the same. glob.glob (so far as I can make out) does a *wildcard* search for directories matching a *single* pattern. My suggestion needs a *non-recursive* search for a *file* in a *list* of *non-wildcarded* directories. Best wishes Rob Cliffe They don't give you "search in a list of directories" intrinsically, but that's simple loop, bailing out on a match, no? pathlib's glob method is more like glob.glob than os.walk - though there's also a walk method in pathlib that's in the same spirit as os.walk. The globs are only recursive if you ask them to be, and if you don't want wildcarding, don't include any wildcard characters in the pattern. Yes, but if I understand correctly, they all start from a single directory (and work downwards if required). My suggestion involved searching a *list* (possibly multiple lists) of directories. Rob -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Best practice for config files?
On 22/05/2025 15.27, Stefan Ram wrote: "Michael F. Stemper" wrote or quoted: Should I specify the location of the config file with a command-line option, or is requiring the program to be executed in the directory containing the configuration file considered acceptable practice? It was me who digged out this "platformdirs" "user_config_dir" API using a source code search on my harddisk without any help. But then I asked my buddy, the chatbot, to explain how to use it, which I include here, followed by some more words of my own at the end. Chatbot: [massive snip] On Linux: ~/.config/YourAppName [another one] Wow, if that's the best practice, I'll settle for second-best! Somebody who wished to remain anonymous contacted me via email and suggested that I could have my cake and eat it, too. I am going ahead with having a default location for the config file, as well as a command-line option to specify a different file. Blindingly obvious! And the default will not be in the directory in which the program is being run. Your post reminded me of the existence of $HOME/.config which is obviously the right place for it. Thanks for all of the suggestions. -- Michael F. Stemper I refuse to believe that a corporation is a person until Texas executes one. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Best practice for config files?
On 22/05/2025 20:59, Michael F. Stemper wrote:
I recently wrote a program to do some record-keeping for me. I found
myself hard-coding a bunch of different values into it. This didn't
seem right, so I made my first use of configparser.ConfigParser().
Created the configuration file and everything is working fine.
However, I wrote it based on the assumption that the program is
running in the directory where the config file is stored, and has
a specific name. I started having some second thoughts here.
I thought about putting the location of the configuration file in
the configuration file, but that seemed like a non-starter.[1]
Should I specify the location of the config file with a command-line
option, or is requiring the program to be executed in the directory
containing the configuration file considered acceptable practice?
[1] See Tegan Jovanka in _Castrovalva_ for more on this idea.
So, I use an environment variable because my config is shared between Python
and Java auto test frameworks. I think keeping the config adjacent to the
.py files is also workable because a Python program can know where it is:
from pathlib import Path
script_path = Path(__file__).resolve()
script_directory = script_path.parent
print(f"The script is located at: {script_path}")
print(f"The script is located in the directory: {script_directory}")
--
A PICKER OF UNCONSIDERED TRIFLES
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Searching for a file
On 23/05/2025 18:55, Mats Wichmann wrote: On 5/22/25 21:04, Rob Cliffe via Python-list wrote: 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: consider: os.walk, glob.glob, Path.glob I have. None of these are appropriate. os.walk iterates *recursively* over a *single* directory and its subdirectories. pathlib.Path.glob so far as I can make out (I have never used pathlib) does much the same. glob.glob (so far as I can make out) does a *wildcard* search for directories matching a *single* pattern. My suggestion needs a *non-recursive* search for a *file* in a *list* of *non-wildcarded* directories. Best wishes Rob Cliffe -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Best practice for config files?
On 2025-05-23, Thomas Passin wrote: >> Alternatively look at the PATH envronment variable, which >> contains a list of directories separated by semicolons and which you can >> access as os.environ['PATH'] . > > There is really no reason for a config file to be on the system > path. On Unix/Linux I would _never_ expect a config file to be in the PATH. PATH is for executables. Executables and config files are not stored together. That's simply not how it's done on Unix. There is sort of a traditional set of locations where applications look to find a config file: $HOME/ $HOME/.config/ $HOME/.config// /etc/ /etc// /usr/local/etc/ /usr/local/etc// The last two overried all of the others. Config files that reside in $HOME/ usually start with a dot. Often they end in 'rc'. Config files in other directories usually don't start with a dot. There's usually an directory only when an app needs multiple config files. If an app only has one config file, tradition is that you don't need a directory for it. Many applications will parse two config files: a global one from /etc or /usr/local/ and a user-one from somewhere under $HOME. However, it varies a lot from one application to another... > On Windows, if it's not in the program's home directory (or a subdir > of it), then it's common to be in the user's home directory. That's > assuming the program is expected to have possibly different > configurations for different users. > > Otherwise there's a \Users\Public directory (or [...] > > The most flexible plan would be to have the program look in all > those likely places for its config file. For more flexibility - but > this is unnecessarily complicated for many applications - have the > program look first on the command line for the config directory, > then for an environmental variable, then in those likely places. -- https://mail.python.org/mailman3//lists/python-list.python.org
Searching for a file
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
--
https://mail.python.org/mailman3//lists/python-list.python.org
Re: Best practice for config files?
On 22/05/2025 23:45, Mats Wichmann wrote: On 5/22/25 13:59, Michael F. Stemper via Python-list wrote: I recently wrote a program to do some record-keeping for me. I found myself hard-coding a bunch of different values into it. This didn't seem right, so I made my first use of configparser.ConfigParser(). Created the configuration file and everything is working fine. However, I wrote it based on the assumption that the program is running in the directory where the config file is stored, and has a specific name. I started having some second thoughts here. I thought about putting the location of the configuration file in the configuration file, but that seemed like a non-starter.[1] Should I specify the location of the config file with a command-line option, or is requiring the program to be executed in the directory containing the configuration file considered acceptable practice? Eh, there are so many context-dependent practices that it's largely impossible to identify something to call a "best practice" these days. I'm going to make a couple of comments, but there's more to consider than just these thoughts. There's a sort-of-standard package called platformdirs (a successor to appdirs) which tries to tell you where to put things in a platform-independent way. https://pypi.org/project/platformdirs/ https://pypi.org/project/appdirs/ This works nicely if you're building something to distribute, and you want to have a system-neutral way to access a config file. For personal stuff, that may be overkill. If it's only for you, just do what works. Enhancement: have a default location for the config file hard-coded, but provide a cmdline option to give an alternative. Mats is absolutely correct that there is no "one size fits all" solution. However one solution that might or might not suit you (at least on WIndows; I hope it's applicable to Unix) is to look at sys.path and search for your configuration file in every directory it lists until you find it (or give an error message if it isn't). Alternatively look at the PATH envronment variable, which contains a list of directories separated by semicolons and which you can access as os.environ['PATH'] . Best wishes, Rob Cliffe -- https://mail.python.org/mailman3//lists/python-list.python.org
Best practice for config files?
I recently wrote a program to do some record-keeping for me. I found myself hard-coding a bunch of different values into it. This didn't seem right, so I made my first use of configparser.ConfigParser(). Created the configuration file and everything is working fine. However, I wrote it based on the assumption that the program is running in the directory where the config file is stored, and has a specific name. I started having some second thoughts here. I thought about putting the location of the configuration file in the configuration file, but that seemed like a non-starter.[1] Should I specify the location of the config file with a command-line option, or is requiring the program to be executed in the directory containing the configuration file considered acceptable practice? [1] See Tegan Jovanka in _Castrovalva_ for more on this idea. -- Michael F. Stemper If it isn't running programs and it isn't fusing atoms, it's just bending space. -- https://mail.python.org/mailman3//lists/python-list.python.org
Re: Dynamic classes
> I have created a dynamic class using the type() function:
> x = type('MyFlags', (), {'Flag1': 1, 'Flag2': 2, 'Flag3: 4, ' '__init__' :
> __init__})
I find that it's generally more convenient to do this using similar code:
def constructor(flag1, flag2):
class _Hidden:
def __init__(self):
self.flag1 = flag1
self.flag2 = flag2
return _Hidden()
h = constructor('Flag1', 'Flag2')
This accomplishes the same goal (with some overhead, perhaps), but is
easier to format, the editor will recognize that you are writing a
class rather than a bunch of data bits, you will have the ability to
define the methods together with the class, benefit from the class
initialization environment (eg. by using @static or @property
decorators etc.). Also, this allows class parametrization in ways that
are difficult to accomplish using metaclasses and other complicated
mechanisms Python language provides to that end. Eg. you can
conditionally inherit from different superclasses (so, you can use
this approach as a factory that creates different classes), or you can
conditionally add methods, conditionally provide different method
bodies, conditionally provide different arguments to parametrized
decorators.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dynamic classes
On 20/05/25 4:33 am, Stefan Ram wrote: So, the reason you're getting that TypeError is your __init__ function isn't actually hooked up right when you build your class with "type". You got to set up your init before you call "type", and then drop it into the class dictionary as a /function/ (not as a string). That's what he did, or at least that's what he tried to do. It turns out the misplaced quote was the entire problem -- by a fluke, it didn't result in a syntax error, and ended up putting the __init__ function into the dict under the name 'Flag3: 4, __init__'. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Dynamic classes
On 19/05/2025 23:11, Thomas Passin via Python-list wrote:
On 5/19/2025 5:49 PM, Mats Wichmann via Python-list wrote:
On 5/19/25 09:51, Jonathan Gossage via Python-list wrote:
I have created a dynamic class using the type() function:
x = type('MyFlags', (), {'Flag1': 1, 'Flag2': 2, 'Flag3: 4, '
'__init__' :
__init__})
This is not my area of expertise, but there is a misplaced quote before
'__init__'
that should be after
'Flags3
Correct this, and your example runs without error.
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dynamic classes
On 5/19/2025 5:49 PM, Mats Wichmann via Python-list wrote:
On 5/19/25 09:51, Jonathan Gossage via Python-list wrote:
I have created a dynamic class using the type() function:
x = type('MyFlags', (), {'Flag1': 1, 'Flag2': 2, 'Flag3: 4, '
'__init__' :
__init__})
The new class is there, and the class variables, Flag1, Flag2, and Flag3,
are present correctly. However, when I try to create an instance of this
class with the following code:
y = x('Flag1', 'Flag2')
it fails with a TypeError stating that 'MyFlags' does not accept
arguments.
What do I have to do to make this happen?. BTW __init__(self, *args) is
defined as the instance initializer.
Might help if you show the init function. I've done something similar to
this without trouble, but not using the unpacking (i.e. *args). I used
this in an ancient blog post (thus, pre-typing, and such):
def transact(acct, amount):
acct.balance += amount
def pay_interest(acct):
acct.balance += acct.balance * acct.interest_rate
def account_init(acct, num, name, bal, rate):
acct.acct_number = num
acct.acct_holder = name
acct.balance = bal
acct.interest_rate = rate
account = {
"acct_number": "XXX",
"acct_holder": "",
"balance": 0.0,
"interest_rate": 0.0,
"transact": transact,
"pay_interest": pay_interest,
"__init__": account_init,
}
AccountType = type("AccountType", (), account)
myaccount = AccountType("1234567", "J. Q. Public", 20.0, 0.01)
print(myaccount.balance)
myaccount.transact(-10)
print(myaccount.balance)
myaccount.pay_interest()
print(myaccount.balance)
It's interesting that in Jython there is a way to do something
conceptually similar to turn a Jython class into a Java class. Here's
one of mine:
synchronized CoordinatorType getCoord() {
JythonObjectFactory factory = new JythonObjectFactory (
// Type class, Jython module name, class name
CoordinatorType.class, "Coordinator", "Coordinator");
// Java class
CoordinatorType coord = (CoordinatorType) factory.createObject();
return coord;
}
// Instantiate a Coordinator
// Error handling elided for clarity
CoordinatorType c;
c = getCoord();
--
https://mail.python.org/mailman/listinfo/python-list
Re: Dynamic classes
On 5/19/25 09:51, Jonathan Gossage via Python-list wrote:
I have created a dynamic class using the type() function:
x = type('MyFlags', (), {'Flag1': 1, 'Flag2': 2, 'Flag3: 4, ' '__init__' :
__init__})
The new class is there, and the class variables, Flag1, Flag2, and Flag3,
are present correctly. However, when I try to create an instance of this
class with the following code:
y = x('Flag1', 'Flag2')
it fails with a TypeError stating that 'MyFlags' does not accept arguments.
What do I have to do to make this happen?. BTW __init__(self, *args) is
defined as the instance initializer.
Might help if you show the init function. I've done something similar to
this without trouble, but not using the unpacking (i.e. *args). I used
this in an ancient blog post (thus, pre-typing, and such):
def transact(acct, amount):
acct.balance += amount
def pay_interest(acct):
acct.balance += acct.balance * acct.interest_rate
def account_init(acct, num, name, bal, rate):
acct.acct_number = num
acct.acct_holder = name
acct.balance = bal
acct.interest_rate = rate
account = {
"acct_number": "XXX",
"acct_holder": "",
"balance": 0.0,
"interest_rate": 0.0,
"transact": transact,
"pay_interest": pay_interest,
"__init__": account_init,
}
AccountType = type("AccountType", (), account)
myaccount = AccountType("1234567", "J. Q. Public", 20.0, 0.01)
print(myaccount.balance)
myaccount.transact(-10)
print(myaccount.balance)
myaccount.pay_interest()
print(myaccount.balance)
--
https://mail.python.org/mailman/listinfo/python-list
Dynamic classes
I have created a dynamic class using the type() function:
x = type('MyFlags', (), {'Flag1': 1, 'Flag2': 2, 'Flag3: 4, ' '__init__' :
__init__})
The new class is there, and the class variables, Flag1, Flag2, and Flag3,
are present correctly. However, when I try to create an instance of this
class with the following code:
y = x('Flag1', 'Flag2')
it fails with a TypeError stating that 'MyFlags' does not accept arguments.
What do I have to do to make this happen?. BTW __init__(self, *args) is
defined as the instance initializer.
--
Jonathan Gossage
--
https://mail.python.org/mailman/listinfo/python-list
Re: Trailer for upcoming Python documentary
Am 18.05.2025 22:16 schrieb Larry Martell via Python-list: https://youtu.be/pqBqdNIPrbo?si=P2ukSXnDj3qy3HBJ Awesome! Which release channels will be used? How can we pay? -- https://mail.python.org/mailman/listinfo/python-list
Re: Trailer for upcoming Python documentary
On 5/18/25 15:16, Larry Martell wrote: https://youtu.be/pqBqdNIPrbo?si=P2ukSXnDj3qy3HBJ Get ready Guido: "I'd like to thank the Academy ..." -- https://mail.python.org/mailman/listinfo/python-list
Re: WG: dont use C:\Windows as working directory when installed using microsoft store
On 5/18/25 08:39, Mike Dewhirst via Python-list wrote: Apologies for top-posting. It's my phone's fault.Since no-one appears to have responded, I'll stir up some aggro and offer my opinion based on ~45 years experience with Microsoft.Uninstall python/idle etc completely and download from python.org instead. I would advise ignoring recommendations and install to c:/python313 or whatever version suits. From then, I would establish a virtual environment for each project and ignore Windows paths. The clever things built into Windows specific kit have built-in assumptions which probably suit some people but not you. Nor me.Good luck.Mike --Unsigned mail from my phone I did respond and something went wrong with the copy that was supposed to go to the list, still need to investigate why. IDLE uses the directory it was started in. That's absolutely fine if you're in a directory you want to work in, and you type "idle" to a command-line shell. If you launch IDLE, like any command, by clicking on an icon, the start directory depends on how desktop-style launching works (it doesn't have the context of a "current working directory" that you have in a shell), and on configuration settings. Without configuration (whether by the user explicitly, or by the way the launch icon is set up during program installation), it's likely to be the location of the icon file, or some other uninteresting place. It's not just Windows where problems have happened with IDLE using current-directory that's not what folks expect - you can find grumbles for Mac as well if you look on the Internet. Configuring the launch directory for a command run via an icon is very system-specific. On Windows you can configure the properties of the icon (the real one, not the one in the launch menu, which is a shortcut)... except, as in the OP's case, if you used the Store version, which is an "app", where you apparently can't. Store apps have some special restrictions, which, in my possibly slightly less radical opinion, means the Python one is not really worth using. So: - start IDLE from a shell prompt (change directory first if you want a special dev dir) - use the python.org version and configure the launch dir via the icon - use one of the many good editors/IDEs that handle all this stuff. yes that's not a "battery includes" thing like IDLE is, but hey... there are many of these, free, proprietary, or in between. A pair of community-curated lists are at: https://wiki.python.org/moin/IntegratedDevelopmentEnvironments https://wiki.python.org/moin/PythonEditors and there are also a several-digit number of internet sites that promise "the Best Python Editors" and that kind of click-baity thing... -- https://mail.python.org/mailman/listinfo/python-list
Trailer for upcoming Python documentary
https://youtu.be/pqBqdNIPrbo?si=P2ukSXnDj3qy3HBJ -- https://mail.python.org/mailman/listinfo/python-list
RE: WG: dont use C:\Windows as working directory when installed using microsoft store
Apologies for top-posting. It's my phone's fault.Since no-one appears to have responded, I'll stir up some aggro and offer my opinion based on ~45 years experience with Microsoft.Uninstall python/idle etc completely and download from python.org instead. I would advise ignoring recommendations and install to c:/python313 or whatever version suits. From then, I would establish a virtual environment for each project and ignore Windows paths. The clever things built into Windows specific kit have built-in assumptions which probably suit some people but not you. Nor me.Good luck.Mike --Unsigned mail from my phone Original message ----From: T N via Python-list Date: 17/5/25 12:54 (GMT+10:00) To: python-list@python.org Subject: WG: dont use C:\Windows as working directory when installed using microsoft store Von: T NGesendet: Samstag, 17. Mai 2025 04:33An: idle-dev@python.orgBetreff: dont use C:\Windows as working directory when installed using microsoft storeHi,ive installed python with IDLE using the microsoft store, but one big issue with it:whenever i try to save a new file it prompts me to put it in C:\Windows\ which is not a good idea, %userprofile% or %userprofile%\Documents\ would be more appropriate. Normally i just change the value of "start in" on the .lnk in the start menu but in case of an app this is not possibleso please fix thatThanks a lot in advance and keep up the good workTN-- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
WG: dont use C:\Windows as working directory when installed using microsoft store
Von: T N Gesendet: Samstag, 17. Mai 2025 04:33 An: idle-...@python.org Betreff: dont use C:\Windows as working directory when installed using microsoft store Hi, ive installed python with IDLE using the microsoft store, but one big issue with it: whenever i try to save a new file it prompts me to put it in C:\Windows\ which is not a good idea, %userprofile% or %userprofile%\Documents\ would be more appropriate. Normally i just change the value of "start in" on the .lnk in the start menu but in case of an app this is not possible so please fix that Thanks a lot in advance and keep up the good work TN -- https://mail.python.org/mailman/listinfo/python-list
IDLE: dark mode on windows?
Hi there, i hope you can help me and this is the right address, i tried mailing idle-...@python.org but it bounced, please forward if possible, ive got IDLE 3.7.9 on windows 10, and windows 10 is set to dark mode, but all windows by IDLE are bright as a painful light, is there any way to make it all like dark mode? i managed to switch the console/edit area to dark mode using the attatched hack, but that looks even worse cause now title, menu/scroll and status bar are bright and only the center edit is dark, a bit better then before but not as nice as i want. I know from expirences using tk based software under linux that it is possible to get something like dark mode, i dont know how exactly i did it but i guess it was not that hard, probably some color changes in the desktop enviorment that not only changed gtk's and qt's behavior but also tk's or some other stuff like that thing that makes xterm switch to dark mode... But under windows i would like that it , in an ideal case, just acts based on the global setting introduced since windows 10, maybe implement that in coming versions... Or is there any other way to hack this by putting some tk config files somewhere. i would aprichiate any help on that. thanks a lot in advance, Tim from Hamburg -- https://mail.python.org/mailman/listinfo/python-list
Re: [egenix-info] ANN: eGenix Antispam Bot for Telegram 0.7.1
Hi Schimon, thanks for reaching out. Our bot is TG-only, since we built it for our user group chat group running on TG. But I suppose you can make use of the types of challenges we use for XMPP and IRC as well. The strategies are working quite well for us, even though they are not perfect. It reduces the admin work substantially, plus it's easy to extend, so we can always tune them or add new ones. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 14 2025) >>> 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/ On 14.05.2025 17:59, Schimon Jehudah wrote: Good evening. Is this service also available for XMPP? I am working on a similar project which is called KaikOut, and I will be glad to collaborate. https://git.xmpp-it.net/sch/KaikOut Moderation service for XMPP Currently, it supports XMPP, and in future it would also support IRC. Kind regards, Schimon On Wed, 14 May 2025 13:42:22 +0200 eGenix Team via Python-list wrote: *ANNOUNCING* eGenix Antispam Bot for Telegram Version 0.7.1 A simple, yet effective bot implementation to address Telegram signup spam. This announcement is also available on our web-site for online reading: https://www.egenix.com/company/news/eGenix-Antispam-Bot-for-Telegram-0.7.1-GA.html *INTRODUCTION* eGenix <https://egenix.com/> has long been running a local Python user group meeting in Düsseldorf called /Python Meeting Düsseldorf <https://pyddf.de/>/ and we are using a Telegram group for most of our communication. In the early days, the group worked well and we only had few spammers joining it, which we could well handle manually. More recently, this has changed dramatically. We are seeing between 2-5 spam signups per day, often at night. Furthermore, the signups accounts are not always easy to spot as spammers, since they often come with profile images, descriptions, etc. With the bot, we now have a more flexible way of dealing with the problem. Please see our project page for details and download links: https://www.egenix.com/library/telegram-antispam-bot/ *FEATURES* * Low impact mode of operation: the bot tries to keep noise in the group to a minimum * Several challenge mechanisms to choose from, more can be added as needed * Flexible and easy to use configuration * Only needs a few MB of RAM, so can easily be put into a container or run on a Raspberry Pi * Can handle quite a bit of load due to the async implementation * Works with Python 3.9+ * MIT open source licensed *NEWS* The 0.7.1 release fixes a few bugs and adds more features: * Added missing dependency on emoji package to setup (bug introduced in 0.7.0, fixed in 0.7.1) * Added user name check for number of emojis, since these are being used a lot by spammers * Added wheel as requirement, since this is no longer included per default * Updated copyright year It has been battle-tested in production for several years already already and is proving to be a really useful tool to help with Telegram group administration. Enjoy, -- https://mail.python.org/mailman/listinfo/python-list
[ANN] New version 2.1.0 of L.Pointal's Python 3 Cheat Sheet
Hello, In the context of a move for hosting of my one recto-verso pdf cheat sheet, I updated it to add Python's news stuff and make a new 2.1.0 version (latest version, 2.0.6, was from 2017). DOWNLOAD English version is at https://py3cheatsheet.lisn.fr/ (its a short URL fore real hosting) MODIFICATIONS = * Add assignment := (morse) operator * Add match ... case instruction * For strings formating, switch to f-strings * Add str methods .format(), .removeprefix(), .removesuffix() * Revised for loops on index to use enumerate with index, value * Add functionnal programming map and filter list comprehension expressions * Add dict's | merge and |= update operators * Reorganize sequences index sectionto make room * Add with () group of context to open multiple files A+ L.Pointal. -- https://mail.python.org/mailman/listinfo/python-list
Re: [egenix-info] ANN: eGenix Antispam Bot for Telegram 0.7.1
Marc-Andre. Good evening. Thank you for your respond. I will definitely explore your project. The XMPP modules are atomized in a single directory /interface/xmpp/ in order to make it extendible to other interfaces (i.e. protocols). I do consider to transform the directory of XMPP modules into a framework for building XMPP bots. I sense, that collaboration be feasible. Kind regards, Schimon On Wed, 14 May 2025 19:19:01 +0200 Marc-Andre Lemburg wrote: > Hi Schimon, > > thanks for reaching out. Our bot is TG-only, since we built it for > our user group chat group running on TG. > > But I suppose you can make use of the types of challenges we use for > XMPP and IRC as well. > > The strategies are working quite well for us, even though they are > not perfect. It reduces the admin work substantially, plus it's easy > to extend, so we can always tune them or add new ones. > > Thanks, -- https://mail.python.org/mailman/listinfo/python-list
Re: ANN: eGenix Antispam Bot for Telegram 0.7.1
Good evening. Is this service also available for XMPP? I am working on a similar project which is called KaikOut, and I will be glad to collaborate. https://git.xmpp-it.net/sch/KaikOut Moderation service for XMPP Currently, it supports XMPP, and in future it would also support IRC. Kind regards, Schimon On Wed, 14 May 2025 13:42:22 +0200 eGenix Team via Python-list wrote: > *ANNOUNCING* > > > eGenix Antispam Bot for Telegram > > Version 0.7.1 > > A simple, yet effective bot implementation > to address Telegram signup spam. > > This announcement is also available on our web-site for online > reading: > https://www.egenix.com/company/news/eGenix-Antispam-Bot-for-Telegram-0.7.1-GA.html > > > *INTRODUCTION* > > eGenix <https://egenix.com/> has long been running a local Python > user group meeting in Düsseldorf called /Python Meeting Düsseldorf > <https://pyddf.de/>/ and we are using a Telegram group for most of > our communication. > > In the early days, the group worked well and we only had few spammers > joining it, which we could well handle manually. > > More recently, this has changed dramatically. We are seeing between > 2-5 spam signups per day, often at night. Furthermore, the signups > accounts are not always easy to spot as spammers, since they often > come with profile images, descriptions, etc. > > With the bot, we now have a more flexible way of dealing with the > problem. > > Please see our project page for details and download links: > > https://www.egenix.com/library/telegram-antispam-bot/ > > > *FEATURES* > > * Low impact mode of operation: the bot tries to keep noise in the > group to a minimum > * Several challenge mechanisms to choose from, more can be added as > needed > * Flexible and easy to use configuration > * Only needs a few MB of RAM, so can easily be put into a container > or run on a Raspberry Pi > * Can handle quite a bit of load due to the async implementation > * Works with Python 3.9+ > * MIT open source licensed > > > > *NEWS* > > The 0.7.1 release fixes a few bugs and adds more features: > > * Added missing dependency on emoji package to setup (bug introduced > in 0.7.0, fixed in 0.7.1) > * Added user name check for number of emojis, since these are being > used a lot by spammers > * Added wheel as requirement, since this is no longer included per > default > * Updated copyright year > > It has been battle-tested in production for several years already > already and is proving to be a really useful tool to help with > Telegram group administration. > > > Enjoy, > -- https://mail.python.org/mailman/listinfo/python-list
ANN: eGenix Antispam Bot for Telegram 0.7.1
*ANNOUNCING* eGenix Antispam Bot for Telegram Version 0.7.1 A simple, yet effective bot implementation to address Telegram signup spam. This announcement is also available on our web-site for online reading: https://www.egenix.com/company/news/eGenix-Antispam-Bot-for-Telegram-0.7.1-GA.html *INTRODUCTION* eGenix <https://egenix.com/> has long been running a local Python user group meeting in Düsseldorf called /Python Meeting Düsseldorf <https://pyddf.de/>/ and we are using a Telegram group for most of our communication. In the early days, the group worked well and we only had few spammers joining it, which we could well handle manually. More recently, this has changed dramatically. We are seeing between 2-5 spam signups per day, often at night. Furthermore, the signups accounts are not always easy to spot as spammers, since they often come with profile images, descriptions, etc. With the bot, we now have a more flexible way of dealing with the problem. Please see our project page for details and download links: https://www.egenix.com/library/telegram-antispam-bot/ *FEATURES* * Low impact mode of operation: the bot tries to keep noise in the group to a minimum * Several challenge mechanisms to choose from, more can be added as needed * Flexible and easy to use configuration * Only needs a few MB of RAM, so can easily be put into a container or run on a Raspberry Pi * Can handle quite a bit of load due to the async implementation * Works with Python 3.9+ * MIT open source licensed *NEWS* The 0.7.1 release fixes a few bugs and adds more features: * Added missing dependency on emoji package to setup (bug introduced in 0.7.0, fixed in 0.7.1) * Added user name check for number of emojis, since these are being used a lot by spammers * Added wheel as requirement, since this is no longer included per default * Updated copyright year It has been battle-tested in production for several years already already and is proving to be a really useful tool to help with Telegram group administration. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, May 14 2025) 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/ -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On 5/8/2025 2:05 AM, Left Right via Python-list wrote:
Also, it appears that the change linked above is a lie:
https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-python-grammar-longstringitem
According to the grammar, any character can follow backslash in a
valid Python program. The warning / error raised by this code should
not be a syntax error / warning because the syntax is correct.
"Changed in version 3.12: Unrecognized escape sequences produce a
SyntaxWarning. In a future Python version they will be eventually a
SyntaxError."
See https://docs.python.org/3/reference/lexical_analysis.html#strings
Test case for "\" in triple-quoted string:
[code]
def f():
..."""\hello"""
:2: SyntaxWarning: invalid escape sequence '\h'
...print('hi')
...
f()
hi
[/code]
This example fits the documentation exactly. A SyntaxWarning is emitted
for the unrecognized escape sequence "\h". The program runs as intended.
Please let's drop all the OT back-and-forth.
On Thu, May 8, 2025 at 7:54 AM Left Right wrote:
I think it could be this:
A backslash-character pair that is not a valid escape sequence now
generates a SyntaxWarning, instead of DeprecationWarning. For example,
re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an invalid
escape sequence, use raw strings for regular expression:
re.compile(r"\d+\.\d+")). In a future Python version, SyntaxError will
eventually be raised, instead of SyntaxWarning. (Contributed by Victor
Stinner in gh-98401.)
Found in:
https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
It's not supposed to crash your program though. If the program crashes
because of it, it's a bug in Python.
On Thu, May 8, 2025 at 7:00 AM Bob van der Poel via Python-list
wrote:
Did something change in python buggering up my use of a "\ " sequence in a
triple quoted string?
I have yet to go through my archive on the program, but I tried to run it
today and it crashed quite spectacularly when it hit a """ """ line
being used as a comment at the top of a function. I changed the "\" to a
"/" and all is well now.
--
Listen to my FREE CD at http://www.mellowood.ca/music/cedars
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW: http://www.mellowood.ca
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On 13/05/25 6:28 am, Left Right wrote: Read the associate release note. I take it you're referring to this: In a future Python version, SyntaxError will eventually be raised, instead of SyntaxWarning. (Contributed by Victor Stinner in gh-98401.) That doesn't contradict what I said. Currently it's a warning. If and when it becomes an error, presumably the grammar documentation will be updated to reflect that. If it isn't, you'll have cause to complain, but not before. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Left Right writes:
>> Second, the word "lie" is far more harsh than what I presume
>> you meant to say. For me, and I think for most people, the word
>> "lie" implies a deliberate intent to deceive.
>
> No, it doesn't. Consider Joseph Conrand's Heart of Darkness,
No, thank you.
I am trying to help you to understand how people are reacting to
your posts. I suggested that saying that the grammar is incorrect
or contains an error would have expressed exactly what you intended
without triggering hostile reactions, which I'm assuming you
don't want.
[...]
> English literature lessons aside, even if you believe what you believe
> about the meaning of the word, you could at least try to find the
> irony, that was the larger goal, than to immediately presume you are
> being attacked, and start retaliating instead of looking into the
> problem.
I'm not aware that I have been attacked or that I have retaliated.
(No need to explain why you might think I have.)
One more thing: your Usenet or email client probably adds an
attribution line above any quoted text. I urge you to leave it
in place. It makes the discussion easier to follow, especially for
those of us who read the comp.lang.python Usenet newsgroup rather
than the mailing list.
I do not intend to reply further.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Chris and Oleg (sp?), please control your tempers; your latter posts added nothing useful to the conversation. (Apologies for the late reply, I was out of town.) -- ~Ethan~ Moderator -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
> Second, the word "lie" is far more harsh than what I presume > you meant to say. For me, and I think for most people, the word > "lie" implies a deliberate intent to deceive. No, it doesn't. Consider Joseph Conrand's Heart of Darkness, the final episode where Marlow comes to Kurtz' widow and tells her about how her husband died. He lies to her, but his intent is not to deceive her, instead, he intends to make sure that her delusion of her late husband is unharmed and that she continues to live that delusion because he judges she will be better off for it. In fact, you yourself used the word deceit, which is to lie with intention to benefit from a lie. But people tell lies for all sorts of reasons. People can lie by omission, through embellishment, by choosing to focus on less relevant aspects of the event. All of these are lies. When a painter mixes white paint into the form shadow of a plaster ball, she lies. When Google Maps puts the destination marker of the restaurant you have a reservation in in the middle of a sea, it lies. English literature lessons aside, even if you believe what you believe about the meaning of the word, you could at least try to find the irony, that was the larger goal, than to immediately presume you are being attacked, and start retaliating instead of looking into the problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
> But the message doesn't say it's an error. It uses the word "warning", > not "error". You're tilting at a straw horse here. Read the associate release note. -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Left Right writes:
> Then it just means that the grammar lies. The two claims are mutually
> exclusive, so either one is a lie or the other or both.
[...]
A couple of points.
First, the convention in this and most other Usenet newsgroups
is to write new text *below* any quoted text. This is known as
"bottom-posting". The alternative, "top-posting" is common in
email in some environments, but tends to cause confusion on Usenet.
It's also a good idea to trim any quoted text that's not relevant to
your followup. See most of the other followups in this newsgroup,
including this one, for examples. Even if you happen to prefer
top-posting, I suggest trying to follow the existing conventions
observed by the vast majority of participants here.
Second, the word "lie" is far more harsh than what I presume
you meant to say. For me, and I think for most people, the word
"lie" implies a deliberate intent to deceive. I don't think you
actually believe that the authors of the documentation you're
complaining about deliberately inserted false information with the
goal of deceiving readers. If you want to say that the grammar
is incorrect, or contains an error, that's something that can be
discussed reasonably. If you say that it "lies", you're making a
claim of malice and making assumptions about someone else's state
of mind with no real basis. Perhaps that's not what the word "lie"
means to you, but I suggest that it explains the harsh reaction to
your initial statement.
--
Keith Thompson (The_Other_Keith) keith.s.thompso...@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--
https://mail.python.org/mailman/listinfo/python-list
PyCon
Anyone going to PyCon? I'll be there, getting in Tuesday night. -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On 12/05/25 3:21 am, Left Right wrote: The point is that the error is wrong. It cannot be a syntax error and at the same time the program compiles. But the message doesn't say it's an error. It uses the word "warning", not "error". You're tilting at a straw horse here. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Why of all people would I respect you? What did you ever do other than insult me? :) Now you are acting surprised? On Sun, May 11, 2025 at 7:38 PM Chris Angelico wrote: > > On Mon, 12 May 2025 at 03:35, Left Right wrote: > > > > https://gitlab.com/doodles-archive/protopy/-/blob/master/cris-angelico-is-a-moron.org?ref_type=heads > > Here's a proof that I have commit rights to this repo > > > > I didn't ask for that, and you don't even have the respect to spell my > name correctly. > > You can leave that there, I don't really care. All it really proves is > that you have zero respect for anyone else. > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On Mon, 12 May 2025 at 03:35, Left Right wrote: > > https://gitlab.com/doodles-archive/protopy/-/blob/master/cris-angelico-is-a-moron.org?ref_type=heads > Here's a proof that I have commit rights to this repo > I didn't ask for that, and you don't even have the respect to spell my name correctly. You can leave that there, I don't really care. All it really proves is that you have zero respect for anyone else. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
https://gitlab.com/doodles-archive/protopy/-/blob/master/protopy/lib/protopy.y?ref_type=heads Here's one. It's not great, not awful. https://gitlab.com/doodles-archive/protopy/-/blob/master/cris-angelico-is-a-moron.org?ref_type=heads Here's a proof that I have commit rights to this repo On Sun, May 11, 2025 at 5:24 PM Chris Angelico wrote: > > On Mon, 12 May 2025 at 01:19, Left Right wrote: > > > > > Have you ever built a language parser? > > > > I've lost count by now. Probably fewer than hundred times though. > > Show me then. Prove it. You're all hot air and opinions and bluster. > Show some actual code, and show that you can do right what you're > complaining that Python has done wrong. > > I'm not holding my breath. > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Oh, so this is where 4chan relocated after they were hacked? What a refined discussion! On Sun, May 11, 2025 at 5:28 PM Chris Angelico wrote: > > On Mon, 12 May 2025 at 01:24, Left Right via Python-list > wrote: > > > > But, sure, go ahead, foam at the mouth, if it > > makes you feel better about it. > > Projecting, much? > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On Mon, 12 May 2025 at 01:24, Left Right via Python-list wrote: > > But, sure, go ahead, foam at the mouth, if it > makes you feel better about it. Projecting, much? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On Mon, 12 May 2025 at 01:19, Left Right wrote: > > > Have you ever built a language parser? > > I've lost count by now. Probably fewer than hundred times though. Show me then. Prove it. You're all hot air and opinions and bluster. Show some actual code, and show that you can do right what you're complaining that Python has done wrong. I'm not holding my breath. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Hahah... what a pile of rubbish. The point is that the error is wrong. It cannot be a syntax error and at the same time the program compiles. You need to choose one. But, sure, go ahead, foam at the mouth, if it makes you feel better about it. -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
> Have you ever built a language parser? I've lost count by now. Probably fewer than hundred times though. -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On 2025-05-11 12:36:31 +0200, Left Right via Python-list wrote:
> Then it just means that the grammar lies.
No, because the parser accepts the sequence. And it produces exactly
what the description says.
The program
#!/usr/bin/python3
print("start")
for i in range(3):
print("\copy")
print("end")
is valid and prints
start
\copy
\copy
\copy
end
to stdout, as you would expect from reading the docs.
But in addition to that it also prints the *warning* (not error, that's
a difference)
/home/hjp/tmp/./foo:5: SyntaxWarning: invalid escape sequence '\c'
print("\copy")
to stderr (this is also documented).
One can quibble over the exact wording of the warning ("unrecognized"
would be more in line with the documentation than "invalid"), but there
are reasons for the warning.
> The two claims are mutually exclusive, so either one is a lie or the
> other or both.
No they are not. The grammar says that the program will compile and run,
which it does. The warning tells you that this probably wasn't a good
idea.
Warnings about stuff that is technically correct aren't unusual.
For example, in C something like
#v+
int a = 5, b = 3;
if (a = b) {
printf("a = %d\n", a);
}
#v-
is totally legal (and will print "a = 3"). However, most compilers will
warn about this because it is very likely that the programmer wanted to
write «if (a == b) ...».
> My comment was more of an irony really. It's plenty obvious that the
> grammar is a lie. The reason is that it's tedious to put the actual
> intender rules into the grammar, and so whoever wrote the grammar
> decided to cut corners. But, the grammar is supposed to be the
> authoritative source for how the language is parsed,
Which it is.
> that's why even though it's clear that the grammar is a lie, blaming
> whoever doesn't follow it makes it ironic.
>
> In other words, the grammar author didn't put enough effort into
> making grammar actually work,
But the grammar *does* describe how it actually works. You *can* write
any character after a backslash, and your programm will compile and run.
It is likely that in some future version of Python that will not be the
case any more. *Then* the grammar must be changed. Until then the
documentation should match the current implementation and not something
which may or may not be implemented at some point in the future.
> but seeing how many other things are done in Python, this is not an
> exception. It would've been strange to have it done properly when
> "properly" means doing copious amounts of tedious work.
As usual you're making up your lack of knowledge with an abundance of
opinion.
hjp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On 05/11/2025 6:36 AM EDT Left Right via Python-list <[1]python-list@python.org> wrote: Then it just means that the grammar lies. The two claims are mutually exclusive, so either one is a lie or the other or both. No, it more points out that not all errors are grammatical. The grammar does not (and can not) fully define what is a legal program. Some forms of error are semantic, like undefined symbols. It appears that rather than try to make the grammar complicated enough to describe what is a valid string, that operation was moved into the semantics of a string, which simplifies the rules quite a bit. References Visible links 1. mailto:python-list@python.org -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On Sun, 11 May 2025 at 20:38, Left Right via Python-list wrote: > > My comment was more of an irony really. It's plenty obvious that the > grammar is a lie. The reason is that it's tedious to put the actual > intender rules into the grammar, and so whoever wrote the grammar > decided to cut corners. But, the grammar is supposed to be the > authoritative source for how the language is parsed, that's why even > though it's clear that the grammar is a lie, blaming whoever doesn't > follow it makes it ironic. Have you ever built a language parser? I'm going to guess you haven't. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Then it just means that the grammar lies. The two claims are mutually exclusive, so either one is a lie or the other or both. My comment was more of an irony really. It's plenty obvious that the grammar is a lie. The reason is that it's tedious to put the actual intender rules into the grammar, and so whoever wrote the grammar decided to cut corners. But, the grammar is supposed to be the authoritative source for how the language is parsed, that's why even though it's clear that the grammar is a lie, blaming whoever doesn't follow it makes it ironic. In other words, the grammar author didn't put enough effort into making grammar actually work, but seeing how many other things are done in Python, this is not an exception. It would've been strange to have it done properly when "properly" means doing copious amounts of tedious work. On Sun, May 11, 2025 at 12:11 PM Peter J. Holzer via Python-list wrote: > > On 2025-05-08 08:05:54 +0200, Left Right via Python-list wrote: > > Also, it appears that the change linked above is a lie: > > Such strong words ... > > > > https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-python-grammar-longstringitem > > > > According to the grammar, any character can follow backslash in a > > valid Python program. The warning / error raised by this code should > > not be a syntax error / warning because the syntax is correct. > > Warnings are about technically correct but probably unintended usage. > > The documentation you linked to describes (a bit further down) which > escape sequences are recognized and what happens if you use an > unrecognized escape sequence. It also mentions that using an > unrecognized escape sequence *will* be an error in future versions of > Python. > > A warning is appropriate here. It gives the programmer a chance to fix > the program now before it breaks. > > One could argue that it should say 'unrecognized escape sequence' > instead of 'invalid escape sequence', since it isn't invalid yet, but > that's nitpicking. > > hjp > > -- >_ | Peter J. Holzer| Story must make more sense than reality. > |_|_) | | > | | | h...@hjp.at |-- Charles Stross, "Creative writing > __/ | http://www.hjp.at/ | challenge!" > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
On 2025-05-08 08:05:54 +0200, Left Right via Python-list wrote: > Also, it appears that the change linked above is a lie: Such strong words ... > https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-python-grammar-longstringitem > > According to the grammar, any character can follow backslash in a > valid Python program. The warning / error raised by this code should > not be a syntax error / warning because the syntax is correct. Warnings are about technically correct but probably unintended usage. The documentation you linked to describes (a bit further down) which escape sequences are recognized and what happens if you use an unrecognized escape sequence. It also mentions that using an unrecognized escape sequence *will* be an error in future versions of Python. A warning is appropriate here. It gives the programmer a chance to fix the program now before it breaks. One could argue that it should say 'unrecognized escape sequence' instead of 'invalid escape sequence', since it isn't invalid yet, but that's nitpicking. hjp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
Also, it appears that the change linked above is a lie:
https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-python-grammar-longstringitem
According to the grammar, any character can follow backslash in a
valid Python program. The warning / error raised by this code should
not be a syntax error / warning because the syntax is correct.
On Thu, May 8, 2025 at 7:54 AM Left Right wrote:
>
> I think it could be this:
>
> A backslash-character pair that is not a valid escape sequence now
> generates a SyntaxWarning, instead of DeprecationWarning. For example,
> re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an invalid
> escape sequence, use raw strings for regular expression:
> re.compile(r"\d+\.\d+")). In a future Python version, SyntaxError will
> eventually be raised, instead of SyntaxWarning. (Contributed by Victor
> Stinner in gh-98401.)
>
> Found in:
> https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
>
> It's not supposed to crash your program though. If the program crashes
> because of it, it's a bug in Python.
>
> On Thu, May 8, 2025 at 7:00 AM Bob van der Poel via Python-list
> wrote:
> >
> > Did something change in python buggering up my use of a "\ " sequence in a
> > triple quoted string?
> >
> > I have yet to go through my archive on the program, but I tried to run it
> > today and it crashed quite spectacularly when it hit a """ """ line
> > being used as a comment at the top of a function. I changed the "\" to a
> > "/" and all is well now.
> >
> >
> > --
> >
> > Listen to my FREE CD at http://www.mellowood.ca/music/cedars
> > Bob van der Poel ** Wynndel, British Columbia, CANADA **
> > EMAIL: b...@mellowood.ca
> > WWW: http://www.mellowood.ca
> > --
> > https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: backslash in triple quoted string
I think it could be this:
A backslash-character pair that is not a valid escape sequence now
generates a SyntaxWarning, instead of DeprecationWarning. For example,
re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an invalid
escape sequence, use raw strings for regular expression:
re.compile(r"\d+\.\d+")). In a future Python version, SyntaxError will
eventually be raised, instead of SyntaxWarning. (Contributed by Victor
Stinner in gh-98401.)
Found in:
https://docs.python.org/3/whatsnew/3.12.html#other-language-changes
It's not supposed to crash your program though. If the program crashes
because of it, it's a bug in Python.
On Thu, May 8, 2025 at 7:00 AM Bob van der Poel via Python-list
wrote:
>
> Did something change in python buggering up my use of a "\ " sequence in a
> triple quoted string?
>
> I have yet to go through my archive on the program, but I tried to run it
> today and it crashed quite spectacularly when it hit a """ """ line
> being used as a comment at the top of a function. I changed the "\" to a
> "/" and all is well now.
>
>
> --
>
> Listen to my FREE CD at http://www.mellowood.ca/music/cedars
> Bob van der Poel ** Wynndel, British Columbia, CANADA **
> EMAIL: b...@mellowood.ca
> WWW: http://www.mellowood.ca
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
backslash in triple quoted string
Did something change in python buggering up my use of a "\ " sequence in a triple quoted string? I have yet to go through my archive on the program, but I tried to run it today and it crashed quite spectacularly when it hit a """ """ line being used as a comment at the top of a function. I changed the "\" to a "/" and all is well now. -- Listen to my FREE CD at http://www.mellowood.ca/music/cedars Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: b...@mellowood.ca WWW: http://www.mellowood.ca -- https://mail.python.org/mailman/listinfo/python-list
Python 3.14.0 beta 1 is here!
Only one day late, welcome to the first beta! https://www.python.org/downloads/release/python-3140b1/ This is a beta preview of Python 3.14 Python 3.14 is still in development. This release, 3.14.0b1, is the first 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 (https://github.com/python/cpython/issues). 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. 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 - 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 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. For more details on the changes to Python 3.14, see What’s new in Python 3.14. https://docs.python.org/3.14/whatsnew/3.14.html The next pre-release of Python 3.14 will be 3.14.0b2, scheduled for 2025-05-27. 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 - https://docs.python.org/3.14/whatsnew/3.14.html#incompatible-changes - https://docs.python.org/3.14/whatsnew/3.14.html#removed - https://docs.python.org/3.14/whatsnew/3.14.html#deprecated - https://docs.python.org/3.14/whatsnew/3.14.html#c-api-removed - https://docs.python.org/3.14/whatsnew/3.14.html#c-api-deprecated 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, 3.14 Release Schedule: https://peps.python.org/pep-0745/ - Report bugs at https://github.com/python/cpython/issues - Help fund Python and its community: https://www.python.org/psf/donations/ Note During the release process, we discovered a test that only failed when run sequentially and only when run after a certain number of other tests. This appears to be a problem with the test itself, and we will make it more robust for beta 2. For details, see https://github.com/python/cpython/issues/133532 And now for something completely different The mathematical constant pi is represented by the Greek letter π and represents the ratio of a circle’s circumference to its diameter. The first person to use π as a symbol for this ratio was Welsh self-taught mathematician William Jones in 1706. He was a farmer’s son born in Llanfihangel Tre’r Beirdd on Angelsy (Ynys Môn) in 1675 and only received a basic education at a local charity school. However, the owner of his parents’ farm noticed his mathematical ability and arranged for him to move to London to work in a bank. By age 20, he served at sea in the Royal Navy, teaching sailors
RE: Module urljoin does not appear to work with scheme Gemini
Henry S. Thompson wrote:
> Some approach to support future-proofing in general would seem to be in
> order.
> Given some other precedents, adding a boolean argument called either 'strict'
> or 'lax' would be my preference.
An alternative would be to refactor urllib.parse to use strategy objects
for schemes.
parse.py contains a number of lists of scheme names, that act as flags to
control parsing behaviour:
uses_relative, uses_netloc, uses_params, non_hierarchical, uses_query
and uses_fragment.
(If written today they would be sets, but this is very old code that predates
sets!)
Group that information by scheme instead of by flag name, in e.g. a dataclass,
and
you have made yourself a strategy object lookup table:
scheme_options = {
'https': SchemeOptions(uses_relative=True, uses_netloc=True,
uses_params=True),
'git': SchemeOptions(uses_relative=False, uses_netloc=True,
uses_params=False),
...
}
Once you have that, you can add the strategy object as an optional argument to
functions. If the argument is not given, you find a strategy object from
scheme_options to use. If the argument is given, you use that.
The best part of this approach is that you now have a way of saying "treat this
scheme exactly like https":
from urllib import parse
parse.urljoin('sptth://...', '../one-level-up',
options=parse.scheme_options['https'])
Note: I wrote this before I realised that the lists non_hierarchical, uses_query
and uses_fragment are not used. With only three options instead of six, making
a strategy object is not quite as attractive. But still worth considering.
regards, Anders
--
https://mail.python.org/mailman/listinfo/python-list
Re: Module urljoin does not appear to work with scheme Gemini
Schimon Jehudah writes: > Is there an "ignore" option for "urljoin" to allow schemes that are not > included in the registry of the interpreter of the Python computer > language? Some approach to support future-proofing in general would seem to be in order. Given some other precedents, adding a boolean argument called either 'strict' or 'lax' would be my preference. It would seem that for backwards-compatibility, even though it feels backwards from the in-principle correct approach, it should be either 'strict=True' or 'lax=False'. I note that there are 440 schemes registered [1] as of today, with the following statuses: 275 Provisional 99 Permanent 18 Historical 48 [not given] The (python3.11) implementation of "urljoin" depends on a list of 18 'uses_relative' scheme names: it would be silly to expect anyone to actually check even just the other 81 Permanent schemes to see if they should be added to this list, much less the Provisional or Historical ones, and even sillier to expect that the list ought to be regularly synchronised with the IANA registry. ht [1] https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND e-mail: h...@inf.ed.ac.uk URL: https://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- https://mail.python.org/mailman/listinfo/python-list
Re: Module urljoin does not appear to work with scheme Gemini
Is there an "ignore" option for "urljoin" to allow schemes that are not included in the registry of the interpreter of the Python computer language? I think that it is needed to have, even if it is not registered, as there are ongoing attempts to try to censor Gemini and Gopher. gemini://woodpeckersnest.space/~schapps/journal/2024-05-28-censoring-gemini-and-gopher.gmi Schimon On Tue, 22 Apr 2025 15:33:52 +0100 "Henry S. Thompson" wrote: > Schimon Jehudah via Python-list writes: > > > Yesterday, I have added support for a new syndication format, Gemini > > feed. > > I note that 'gemini' is not (yet?) a registered URI scheme: > > https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml > > ht -- https://mail.python.org/mailman/listinfo/python-list
Re: Module urljoin does not appear to work with scheme Gemini
Schimon Jehudah via Python-list writes: > Yesterday, I have added support for a new syndication format, Gemini > feed. I note that 'gemini' is not (yet?) a registered URI scheme: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND e-mail: h...@inf.ed.ac.uk URL: https://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On Sat, 19 Apr 2025 15:56:16 -0400, Thomas Passin wrote: > My problem with venvs, especially if I have more than one, is that I > eventually forget what they were for and what is different about each > one. If there's only one and it's used for all non-system work, that's > OK but beyond that and they tend to suffer knowledge rot. My Python directory has apple/ create/ fastapi/ lunar/ numerical/ pyside6/ weather/ comics/ django/ folium/ ml/ sqlite/ coursera/ impractical/ nn/ pyqt/ torch/ Not all like sqlite are venvs since no additional modules are needed. Even if I'm a little hazy about 'apple' after a while a quick look at the Python file shows 'https://itunes.apple.com/search' and I remember it is to pull down artist/track info from the itunes database. I also try to remember to run 'pythom -m pip freeze > requirements.txt' after I get everything set up. That way if a OS update installs a new version of Python something like python3 -m venv folium cd folium . bin/activate python -m pip install -r requirements.txt will refresh the venv and install the appropriate packages for the new Python version. That's faster than looking at lib/python3.10/site-packages or whatever the previous version was and adding the dependencies or trying to run the py file and getting Traceback (most recent call last): File "/home/rbowman/work/python/impractical/benford.py", line 5, in import matplotlib.pyplot as plt ModuleNotFoundError: No module named 'matplotlib' -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
Peter J. Holzer wrote: > On 2025-04-18 13:08:36 -0400, Thomas Passin via Python-list wrote: ... >> When the system launches its application the PYTHONPATH will start with >> system site directories; local user site directories will be on the >> PYTHONPATH but since they come later, the python will use PyQt6 v6.8.3 >> because that will come first on the path. No crash here. >> >> If the user has a program that actually does require the use of v6.9.0, he's >> going to have to make sure that the user's local site directories come first >> on the path. One way to do that is to set the PYTHONPATH to point to the >> user's location. > > This is IMHO not practical. The user would have to set PYTHONPATH for > some programs, but not for others. You can't do this with .bashrc (or > similar), the user would have to write a wrapper script for each of > their programs which depend on something in ~/.local. Possible of course > but cumbersome. currently in my .bashrc i have it set up to look for which directory the terminal is in and then runs the activate script for that environment. i like to keep my desktops/projects open with various numbers of terminals available so this way they are all ready to go when the system boots up. > I like Oscar's suggestion that Python scripts provided by the > distribution include -s in the shebang much better. > > Or - what I tend to do - simply use a virtual environment for each > script that needs a package that the system doesn't provide. But of > course that's basically "disable/don't use .local" and all those venvs > take space and need to be maintained. i like that they do not change until i specificly ask them to be changed. ... >> The only one I can think of is for the user, with the help of sudo, or >> by editing some system-enabled script, were to change the global >> PYTHONPATH. That seems a stretch. > > No, there doesn't have to be a global (in the sense that it applies to > all users) PYTHONPATH for that to happen. You just need a PYTHONPATH > that is set for all processes of that user - which the user can > certainly set without sudo (usually by editing .bashrc or maybe using > their desktop environment's settings dialog). yes, that is part of what .bashrc is for, making sure your environment variables are set how you'd like them. songbird -- https://mail.python.org/mailman/listinfo/python-list
Module urljoin does not appear to work with scheme Gemini
Good day.
Yesterday, I have added support for a new syndication format, Gemini
feed.
Yet, it appears that module urljoin fails at its task, even though
module urlsplit correctly handles Gemini.
Python 3.13.3
>>> from urllib.parse import urljoin
>>> urljoin('gopher://gopher.floodgap.com:70/1/overbite', '../one-level-up')
'gopher://gopher.floodgap.com:70/one-level-up'
>>> urljoin('gopher://gopher.floodgap.com:70/1/overbite', 'same-level')
'gopher://gopher.floodgap.com:70/1/same-level'
>>> urljoin('gemini://woodpeckersnest.space/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi',
>>> '../one-level-up')
'../one-level-up'
>>> urljoin('gemini://woodpeckersnest.space/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi',
>>> 'same-level')
'same-level'
>>> from urllib.parse import urlsplit
>>> urlsplit('gopher://gopher.floodgap.com:70/1/overbite')
SplitResult(scheme='gopher', netloc='gopher.floodgap.com:70',
path='/1/overbite', query='', fragment='')
>>> urlsplit('gemini://woodpeckersnest.space/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi')
SplitResult(scheme='gemini', netloc='woodpeckersnest.space',
path='/~schapps/journal/2025-04-20-slixfeed-gemini-and-twtxt.gmi', query='',
fragment='')
>>>
>>>
https://git.xmpp-it.net/sch/Slixfeed/src/branch/master/slixfeed/parser/gmi.py
Is this a problem with the module urljoin?
To whom should reports about such concern be conveyed?
Please advise.
Kind regards,
Schimon
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/19/2025 4:56 AM, Peter J. Holzer via Python-list wrote: On 2025-04-18 13:08:36 -0400, Thomas Passin via Python-list wrote: On 4/18/2025 11:38 AM, Peter J. Holzer via Python-list wrote: On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote: On 18/04/25 9:41 am, Mats Wichmann wrote: There's just not a really great answer to this. Seems to me a system-installed application shouldn't be looking in the user's .local packages in the first place. That should only be for things the user has installed "for this user". It's not the application that looks into .local, it's Python. If you say that a system-installed Python shouldn't look into ~/.local, then you've just disabled that mechanism completely. If not then Python would somehow have to distinguish between system-installed and user-installed scripts. This isn't as easy as checking whether the path starts with /usr/bin or whether it belongs to root. Tying into the system's package manager doesn't look appealing to me (not to mention that it might be unacceptably slow). Let's try a specific example. Let's say that PyQt6 v6.8.3 is installed in the system site directory. The OS uses PyQt6 for some system purposes. Now the user comes along and forces an install of PyQt6 v6.9.0 in the user site directory. 6.9.0 has a bug that would crash one of the system's application but not the user's programs. (This is not a far-fetched scenario). Agreed. Also since PyQt6 is a GUI framework, I'm going to assume that those applications are supposed to be invoked by the user on their desktop, not by a cronjob controlled by the system. When the system launches its application the PYTHONPATH will start with system site directories; local user site directories will be on the PYTHONPATH but since they come later, the python will use PyQt6 v6.8.3 because that will come first on the path. No crash here. If the user has a program that actually does require the use of v6.9.0, he's going to have to make sure that the user's local site directories come first on the path. One way to do that is to set the PYTHONPATH to point to the user's location. This is IMHO not practical. The user would have to set PYTHONPATH for some programs, but not for others. You can't do this with .bashrc (or similar), the user would have to write a wrapper script for each of their programs which depend on something in ~/.local. Possible of course but cumbersome. I like Oscar's suggestion that Python scripts provided by the distribution include -s in the shebang much better. Or - what I tend to do - simply use a virtual environment for each script that needs a package that the system doesn't provide. But of course that's basically "disable/don't use .local" and all those venvs take space and need to be maintained. My problem with venvs, especially if I have more than one, is that I eventually forget what they were for and what is different about each one. If there's only one and it's used for all non-system work, that's OK but beyond that and they tend to suffer knowledge rot. In what scenario is a system application going to load a wrong version of a dependency from a user's site location? When the user sets PYTHONPATH and then accidentally invokes the system-supplied application without resetting it first. The only one I can think of is for the user, with the help of sudo, or by editing some system-enabled script, were to change the global PYTHONPATH. That seems a stretch. No, there doesn't have to be a global (in the sense that it applies to all users) PYTHONPATH for that to happen. You just need a PYTHONPATH that is set for all processes of that user - which the user can certainly set without sudo (usually by editing .bashrc or maybe using their desktop environment's settings dialog). Yes, I agree and I wasn't thinking locally enough. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 2025-04-18 13:08:36 -0400, Thomas Passin via Python-list wrote: > On 4/18/2025 11:38 AM, Peter J. Holzer via Python-list wrote: > > On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote: > > > On 18/04/25 9:41 am, Mats Wichmann wrote: > > > > There's just not a really great answer to this. > > > > > > Seems to me a system-installed application shouldn't be looking in the > > > user's .local packages in the first place. That should only be for things > > > the user has installed "for this user". > > > > It's not the application that looks into .local, it's Python. If you say > > that a system-installed Python shouldn't look into ~/.local, then you've > > just disabled that mechanism completely. If not then Python would > > somehow have to distinguish between system-installed and user-installed > > scripts. This isn't as easy as checking whether the path starts with > > /usr/bin or whether it belongs to root. Tying into the system's package > > manager doesn't look appealing to me (not to mention that it might be > > unacceptably slow). > > Let's try a specific example. Let's say that PyQt6 v6.8.3 is installed in > the system site directory. The OS uses PyQt6 for some system purposes. Now > the user comes along and forces an install of PyQt6 v6.9.0 in the user site > directory. 6.9.0 has a bug that would crash one of the system's application > but not the user's programs. (This is not a far-fetched scenario). Agreed. Also since PyQt6 is a GUI framework, I'm going to assume that those applications are supposed to be invoked by the user on their desktop, not by a cronjob controlled by the system. > When the system launches its application the PYTHONPATH will start with > system site directories; local user site directories will be on the > PYTHONPATH but since they come later, the python will use PyQt6 v6.8.3 > because that will come first on the path. No crash here. > > If the user has a program that actually does require the use of v6.9.0, he's > going to have to make sure that the user's local site directories come first > on the path. One way to do that is to set the PYTHONPATH to point to the > user's location. This is IMHO not practical. The user would have to set PYTHONPATH for some programs, but not for others. You can't do this with .bashrc (or similar), the user would have to write a wrapper script for each of their programs which depend on something in ~/.local. Possible of course but cumbersome. I like Oscar's suggestion that Python scripts provided by the distribution include -s in the shebang much better. Or - what I tend to do - simply use a virtual environment for each script that needs a package that the system doesn't provide. But of course that's basically "disable/don't use .local" and all those venvs take space and need to be maintained. > In what scenario is a system application going to load a wrong version of a > dependency from a user's site location? When the user sets PYTHONPATH and then accidentally invokes the system-supplied application without resetting it first. > The only one I can think of is for the user, with the help of sudo, or > by editing some system-enabled script, were to change the global > PYTHONPATH. That seems a stretch. No, there doesn't have to be a global (in the sense that it applies to all users) PYTHONPATH for that to happen. You just need a PYTHONPATH that is set for all processes of that user - which the user can certainly set without sudo (usually by editing .bashrc or maybe using their desktop environment's settings dialog). hjp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 2025-04-18 17:11:33 +0100, Oscar Benjamin via Python-list wrote: > On Fri, 18 Apr 2025 at 16:50, Peter J. Holzer via Python-list > wrote: > > > > On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote: > > > On 18/04/25 9:41 am, Mats Wichmann wrote: > > > > There's just not a really great answer to this. > > > > > > Seems to me a system-installed application shouldn't be looking in the > > > user's .local packages in the first place. That should only be for things > > > the user has installed "for this user". > > > > It's not the application that looks into .local, it's Python. If you say > > that a system-installed Python shouldn't look into ~/.local, then you've > > just disabled that mechanism completely. If not then Python would > > somehow have to distinguish between system-installed and user-installed > > scripts. This isn't as easy as checking whether the path starts with > > /usr/bin or whether it belongs to root. Tying into the system's package > > manager doesn't look appealing to me (not to mention that it might be > > unacceptably slow). > > Couldn't the system-installed scripts have a shebang like: > > #!/usr/bin/python3 -s Yes, that should work. At least I can't think of any downsides at the moment. hjp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/18/2025 11:38 AM, Peter J. Holzer via Python-list wrote: On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote: On 18/04/25 9:41 am, Mats Wichmann wrote: There's just not a really great answer to this. Seems to me a system-installed application shouldn't be looking in the user's .local packages in the first place. That should only be for things the user has installed "for this user". It's not the application that looks into .local, it's Python. If you say that a system-installed Python shouldn't look into ~/.local, then you've just disabled that mechanism completely. If not then Python would somehow have to distinguish between system-installed and user-installed scripts. This isn't as easy as checking whether the path starts with /usr/bin or whether it belongs to root. Tying into the system's package manager doesn't look appealing to me (not to mention that it might be unacceptably slow). Let's try a specific example. Let's say that PyQt6 v6.8.3 is installed in the system site directory. The OS uses PyQt6 for some system purposes. Now the user comes along and forces an install of PyQt6 v6.9.0 in the user site directory. 6.9.0 has a bug that would crash one of the system's application but not the user's programs. (This is not a far-fetched scenario). When the system launches its application the PYTHONPATH will start with system site directories; local user site directories will be on the PYTHONPATH but since they come later, the python will use PyQt6 v6.8.3 because that will come first on the path. No crash here. If the user has a program that actually does require the use of v6.9.0, he's going to have to make sure that the user's local site directories come first on the path. One way to do that is to set the PYTHONPATH to point to the user's location. In what scenario is a system application going to load a wrong version of a dependency from a user's site location? The only one I can think of is for the user, with the help of sudo, or by editing some system-enabled script, were to change the global PYTHONPATH. That seems a stretch. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On Fri, 18 Apr 2025 at 16:50, Peter J. Holzer via Python-list wrote: > > On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote: > > On 18/04/25 9:41 am, Mats Wichmann wrote: > > > There's just not a really great answer to this. > > > > Seems to me a system-installed application shouldn't be looking in the > > user's .local packages in the first place. That should only be for things > > the user has installed "for this user". > > It's not the application that looks into .local, it's Python. If you say > that a system-installed Python shouldn't look into ~/.local, then you've > just disabled that mechanism completely. If not then Python would > somehow have to distinguish between system-installed and user-installed > scripts. This isn't as easy as checking whether the path starts with > /usr/bin or whether it belongs to root. Tying into the system's package > manager doesn't look appealing to me (not to mention that it might be > unacceptably slow). Couldn't the system-installed scripts have a shebang like: #!/usr/bin/python3 -s -- Oscar -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 2025-04-18 13:24:28 +1200, Greg Ewing via Python-list wrote: > On 18/04/25 9:41 am, Mats Wichmann wrote: > > There's just not a really great answer to this. > > Seems to me a system-installed application shouldn't be looking in the > user's .local packages in the first place. That should only be for things > the user has installed "for this user". It's not the application that looks into .local, it's Python. If you say that a system-installed Python shouldn't look into ~/.local, then you've just disabled that mechanism completely. If not then Python would somehow have to distinguish between system-installed and user-installed scripts. This isn't as easy as checking whether the path starts with /usr/bin or whether it belongs to root. Tying into the system's package manager doesn't look appealing to me (not to mention that it might be unacceptably slow). hjp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 18/04/25 9:41 am, Mats Wichmann wrote: There's just not a really great answer to this. Seems to me a system-installed application shouldn't be looking in the user's .local packages in the first place. That should only be for things the user has installed "for this user". -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/17/25 15:15, Grant Edwards via Python-list wrote: On 2025-04-17, Left Right via Python-list wrote: Also... when installing stuff with pip --user, it is always a package that is not installed for the system (usually not even available for the system). How can that "break system packages"? pip installs dependencies. Dependencies may disagree on the version with the system packages. Good point. I don't generally allow pip to install dependencies, so I forgot about that source of conflict. But as far as I can see, it still can only break stuff for the user, not for the system. The system is never going to look in my ~/.local/lib/python* directories. Sure, and it's "your fault" (sic) if you break yourself. You and I can maybe accept that. But it's usually not obvious that you're done anything to break stuff - you just asked to install something, according to the instructions you read on the project's website, which it's reasonable (?) to expect reflects best practices. Usually a simple "pip install". Say you've been using "MLwiz" installed via a system package. It has two dozen dependencies, some of which have further deps. And it works great. Then you install "Chatbridge" via pip, and it brings with it its own dependencies. It's not really useful to refuse to let it bring its own deps with it since there may be version-specific requirements on its deps, which that project has reasons for. So now you've got a few pkgs in the system with different versions in your .local, and you can't run MLwiz any longer, because a .local pkg (picked up first) conflicts with the requirements of MLwiz. There's just not a really great answer to this. "Use a virtualenv". Fine, but that's still daunting to many, and not necessarily as well described as it could be, and the choice of the word "virtual" in the name makes it sound more complex than it actually is. Projects can certainly do better at describing installation scenarios - at least if they have more than a trivial number of deps, where the conflict chances go up rapidly. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 2025-04-17, Left Right via Python-list wrote: >> Also... when installing stuff with pip --user, it is always a package >> that is not installed for the system (usually not even available for >> the system). How can that "break system packages"? > > pip installs dependencies. Dependencies may disagree on the version > with the system packages. Good point. I don't generally allow pip to install dependencies, so I forgot about that source of conflict. But as far as I can see, it still can only break stuff for the user, not for the system. The system is never going to look in my ~/.local/lib/python* directories. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
> Also... when installing stuff with pip --user, it is always a package > that is not installed for the system (usually not even available for > the system). How can that "break system packages"? pip installs dependencies. Dependencies may disagree on the version with the system packages. This is a difference between eg. how conda works and pip. Conda is an actual package manager: it ensures that all packages in a particular environment agree on version requirements. pip will break your environment in subsequent installs because it doesn't keep track of what was installed before. On top of this, pip may, in general, cause any amount of damage to your system regardless of where or how you install it because by default it's allowed to build wheels from source packages. The build may run whatever code, including formatting hard drives, mining bitcoin etc. The reason it doesn't happen very often is that package maintainers kind of trust each other to be nice. There aren't really any safeguards to prevent malicious actors from doing this, but you would have to want to install their package for some reason. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/17/2025 4:58 AM, Roel Schroeven via Python-list wrote: Op 15/04/2025 om 20:31 schreef Mats Wichmann via Python-list: To be clear: you do not have to activate a virtualenv to use *Python* from it. If you just call the python by the path it's in, it figures everything out (and sets some variables you can query vi sysconfig if you have reason to actually need those details (look for installation schemes). What activating gives you is some path fiddling, and some prompt fiddling (although the prompt fiddling keeps saying it's deprecated). The latter is a visual clue; the former means you can also find *other* commands installed in the virtualenv - including pip. /path/to/virtualenv//bin/python -m pip install ... will work whether you activated or not. pip install ... finds the first command in your PATH named pip, which may or may not be the one in the virtualenv, *unless* you've activated it, because that's the only way the virtualenv bin directory ends up early in your path. Or you can cd to the venv directory and it will be first on the pythonpath. And the pip command that is found and run will use it's own settings regarding where to install packages, even if you activated a virtualenv. For example, you can't use /usr/bin/pip to install something in a virtualenv. pip detects if you are running in a venv and changes its behavior to match. To install something in a virtualenv, you need to use the pip in that virtualenv (either by first activating that venv, or by running something like venv/bin/pip, or venv). (Of course to do that pip needs to be installed in that venv. That might or might not be the case depending on how the venv was created.) I kinda get the feeling that something like that is going on here. IMHO pip should always be run as a module, e.g., python3 -m pip. This way you always get the same pip and environment as the python executable that is being used. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
Op 15/04/2025 om 20:31 schreef Mats Wichmann via Python-list: To be clear: you do not have to activate a virtualenv to use *Python* from it. If you just call the python by the path it's in, it figures everything out (and sets some variables you can query vi sysconfig if you have reason to actually need those details (look for installation schemes). What activating gives you is some path fiddling, and some prompt fiddling (although the prompt fiddling keeps saying it's deprecated). The latter is a visual clue; the former means you can also find *other* commands installed in the virtualenv - including pip. /path/to/virtualenv//bin/python -m pip install ... will work whether you activated or not. pip install ... finds the first command in your PATH named pip, which may or may not be the one in the virtualenv, *unless* you've activated it, because that's the only way the virtualenv bin directory ends up early in your path. And the pip command that is found and run will use it's own settings regarding where to install packages, even if you activated a virtualenv. For example, you can't use /usr/bin/pip to install something in a virtualenv. To install something in a virtualenv, you need to use the pip in that virtualenv (either by first activating that venv, or by running something like venv/bin/pip, or venv). (Of course to do that pip needs to be installed in that venv. That might or might not be the case depending on how the venv was created.) I kinda get the feeling that something like that is going on here. -- "There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened." -- Douglas Adams, The Restaurant at the End of the Universe -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On 4/15/2025 5:38 PM, rbowman via Python-list wrote:
On Tue, 15 Apr 2025 14:12:19 -0400, Thomas Passin wrote:
On Linux, at least, it's standard for pip to install into the user's
site-packages location if it's not invoked with admin privileges - even
without --user. Pip will emit a message saying so. Well, that used to be
true but nowadays Pip wants you to use the --break-system-packages flag
if you want to insist on installing into the system's Python install,
even if it's going to go into --user. I'm not sure if the restriction
will be in place given that the OP built his own Python version.
Is that pip or a distro's version of pip? On Fedora I get the message
about defaulting to user. On Ubuntu I get a message to use a venv or if I
really want a global install to use something like 'pip install python3-
black'. Ubuntu's is pip 24.2, Fedor's is 24.3.1 but neither of them show
'--break-system-packages' in --help.
The behavior is specifed in
https://packaging.python.org/en/latest/specifications/externally-managed-environments/#externally-managed-environments
Exactly how pip works and what messages it emits are specified by this
document, and the details depend on how the distro's packagers configure
it. For example, here is a bit of the spec:
"Before a Python-specific package installer (that is, a tool such as pip
- not an external tool such as apt) installs a package into a certain
Python context, it should make the following checks by default:
Is it running outside of a virtual environment? It can determine
this by whether sys.prefix == sys.base_prefix.
Is there an EXTERNALLY-MANAGED file in the directory identified by
sysconfig.get_path("stdlib", sysconfig.get_default_scheme())?
If both of these conditions are true, the installer should exit with an
error message indicating that package installation into this Python
interpreter’s directory are disabled outside of a virtual environment.
The installer should have a way for the user to override these rules,
such as a command-line flag --break-system-packages. This option should
not be enabled by default and should carry some connotation that its use
is risky."
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pip installs to unexpected place
On Tue, 15 Apr 2025 14:12:19 -0400, Thomas Passin wrote: > On Linux, at least, it's standard for pip to install into the user's > site-packages location if it's not invoked with admin privileges - even > without --user. Pip will emit a message saying so. Well, that used to be > true but nowadays Pip wants you to use the --break-system-packages flag > if you want to insist on installing into the system's Python install, > even if it's going to go into --user. I'm not sure if the restriction > will be in place given that the OP built his own Python version. Is that pip or a distro's version of pip? On Fedora I get the message about defaulting to user. On Ubuntu I get a message to use a venv or if I really want a global install to use something like 'pip install python3- black'. Ubuntu's is pip 24.2, Fedor's is 24.3.1 but neither of them show '--break-system-packages' in --help. -- https://mail.python.org/mailman/listinfo/python-list
