Re: How to 'ignore' an error in Python?
Unsubscribe
On Sat, Apr 29, 2023 at 7:05 PM Chris Angelico wrote:
> On Sun, 30 Apr 2023 at 11:58, Chris Green wrote:
> >
> > Chris Angelico wrote:
> > > On Sat, 29 Apr 2023 at 14:27, Kushal Kumaran
> wrote:
> > > >
> > > > On Fri, Apr 28 2023 at 04:55:41 PM, Chris Green wrote:
> > > > > I'm sure I'm missing something obvious here but I can't see an
> elegant
> > > > > way to do this. I want to create a directory, but if it exists
> it's
> > > > > not an error and the code should just continue.
> > > > >
> > > > > So, I have:-
> > > > >
> > > > > for dirname in listofdirs:
> > > > > try:
> > > > > os.mkdir(dirname)
> > > > > except FileExistsError:
> > > > > # so what can I do here that says 'carry on regardless'
> > > > > except:
> > > > > # handle any other error, which is really an error
> > > > >
> > > > > # I want code here to execute whether or not dirname exists
> > > > >
> > > > >
> > > > > Do I really have to use a finally: block? It feels rather clumsy.
> > > > >
> > > > > I suppose I could test if the directory exists before the
> os.mkdir()
> > > > > but again that feels a bit clumsy somehow.
> > > > >
> > > > > I suppose also I could use os.mkdirs() with exist_ok=True but again
> > > > > that feels vaguely wrong somehow.
> > > > >
> > > >
> > > > Why does exist_ok=True feel wrong to you? This is exactly what it is
> > > > there for.
> > > >
> > >
> > > Using mkdirs when you only want to make one is inviting problems of
> > > being subtly wrong, where it creates too many levels of directory.
> > > Personally, I would just do:
> > >
> > > try: os.mkdir(dirname)
> > > except FileExistsError: pass
> > >
> > > and not try to handle anything else at all.
> > >
> > Yes, OP here, that seems to me to be the 'right' way to do it.
> > Basically I hadn't realised the effect of pass in a try block and
> > that's why I asked the question originally.
> >
>
> There's two points to note here. "pass" doesn't do anything
> whatsoever; it's only there to prevent the syntactic problem of having
> nothing in that block. This will also suppress the error:
>
> try:
> os.mkdir(dirname)
> except FileExistsError:
> dummy = "ignore"
>
> The second thing is that, as soon as you have an "except" clause that
> matches the error, that's it - it stops there. The error is considered
> handled at that point. If that's NOT what you want, you have a few
> options. Firstly, you can simply not have a matching except clause.
> That's why we like to be as precise as possible with our catching;
> every other type of problem will be left uncaught. Secondly, you can
> use "try/finally" to add code that happens as the exception flies by,
> but doesn't catch it (it also happens at the end of the block for
> other reasons). And thirdly, you can reraise the exception:
>
> try:
> os.mkdir(dirname)
> except FileExistsError:
> print("Hey, that one already exists!")
> raise
>
> That's going to keep the exception going just as if it hadn't been
> caught, but with the additional handling.
>
> But if you don't do any of those things, the exception is deemed to be
> handled, and it goes no further.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Fwd: A typing question
Do you want the following? ``` from typing import List, Optional class GLOBALS: foos: Optional[Foos] = None class Foo: def __init__(self): pass class Foos: Foos: List[Foo] = [] def __init__(self): pass GLOBALS.foos = Foos() ``` Kind regards, Sam Ezeh On Sat, 29 Oct 2022 at 22:13, Paulo da Silva < p_d_a_s_i_l_v_a...@nonetnoaddress.pt> wrote: > Hi! > > Consider this simple script ... > > ___ > from typing import List, Optional > > class GLOBALS: > foos=None > > class Foo: > > def __init__(self): > pass > > class Foos: > Foos: List[Foo]=[] > # SOME GLOBALS ARE USED HERE in a real script > > def __init__(self): > pass > > GLOBALS.foos: Optional[Foos]=Foos() > ___ > > Running mypy on it: > pt9.py:18: error: Type cannot be declared in assignment to non-self > attribute > pt9.py:18: error: Incompatible types in assignment (expression has type > "Foos", variable has type "None") > Line 18 is last line and pt9.py is the scrip. > > Replacing last line by > GLOBALS.foos=Foos() > and running mypy still gives the second error. > pt9.py:18: error: Incompatible types in assignment (expression has type > "Foos", variable has type "None") > > What is the common practice in these cases? > > Thank you. > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Virtual PUG-meeting: An applied introduction to Finite State Machines
That seems interesting. Is this hosted online? And are there any suggested reading materials for those who might not be able to attend? Kind regards, Sam Ezeh On Tue, 13 Sept 2022 at 22:53, dn wrote: > An applied introduction to Finite State Machines > 0730 UTC, Wed 21 Sep 2022 > > The basics of Finite State Machines and what they are good for. How to > use FSM for solving optimization problems. > > - A simple traffic jam > - A bigger traffic jam > - A sudoku > > After this lecture there won't be any discrete optimization problem you > won't be able to solve. > > Dr. Bjorn Madsen solves optimization problems using Python, for DoD, > LEGO, Coca Cola, Airbus and many other companies. > > > These meetups have two sessions. At least one is aimed at a beginner > level - in either Python or FSMs. > > Sign-up and more details from https://www.meetup.com/nzpug-auckland/ > -- > Regards, > =dn > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Building on Windows
To add to this, my process was 1. Setup the VM 2. Install Git 3. Clone CPython 4. Run `PCbuild\build.bat -d -e` 5. Notice the error, then install visual studio community 2022 6. Re-run `PCbuild\build.bat -d -e` and see the same error I can't directly copy and paste between the VM and my host desktop but in this scenario, the error was that single line and I can use paste sites where necessary. Kind regards, Sam Ezeh On Sat, 2 Jul 2022 at 15:27, Sam Ezeh wrote: > > I have a Windows virtual machine and I'm following the instructions on > the devguide [1] to build Python inside it. > > When running `PCbuild\build\bat -e -d` I get "Cannot locate > MSBuild.exe on PATH or as MSBUILD variable". I've done a minimal > amount of searching [2][3] but I'm not well-acquainted with Windows > and don't understand the solutions. > > Thanks in advance. > > Kind regards, > Sam Ezeh > > [1]: https://devguide.python.org/compiler/ > [2]: https://bugs.python.org/issue41213 > [3]: https://bugs.python.org/issue33675 -- https://mail.python.org/mailman/listinfo/python-list
Building on Windows
I have a Windows virtual machine and I'm following the instructions on the devguide [1] to build Python inside it. When running `PCbuild\build\bat -e -d` I get "Cannot locate MSBuild.exe on PATH or as MSBUILD variable". I've done a minimal amount of searching [2][3] but I'm not well-acquainted with Windows and don't understand the solutions. Thanks in advance. Kind regards, Sam Ezeh [1]: https://devguide.python.org/compiler/ [2]: https://bugs.python.org/issue41213 [3]: https://bugs.python.org/issue33675 -- https://mail.python.org/mailman/listinfo/python-list
Re: Python installation
Inside my Windows virtual machine only entering `py` as the command brings up the repl, if that helps. Kind Regards, Sam Ezeh On Tue, 21 Jun 2022 at 18:15, Igor Korot wrote: > > Hi, > > On Tue, Jun 21, 2022 at 11:43 AM Brian Karinga wrote: > > > > Hello, > > > > I hope this email finds you well. > > > > I have been trying to download and install the latest version of python on > > my windows device. However, when I run the program, three options arise. > > These are: > > > > Modify > > Repair > > Uninstall > > > > I have executed the modify and repair options several times but nothing has > > changed. Please advise on what the problem could be and how it can be > > resolved. > > Is it possible that Python is already installed? > > Open "Command Prompt" window, type python and press "Enter". > > What do you see on the screen? > > Thank you. > > > > > I look forward to hearing from you. > > > > Thank you, > > Brian. > > -- > > https://mail.python.org/mailman/listinfo/python-list > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Seeking deeper understanding of python equality (==)
Perhaps these source references are useful: Python/ceval.c (_PyEval_EvalFrameDefault) https://github.com/python/cpython/blob/main/Python/ceval.c#L3754-L3768 Objects/object.c (do_richcompare) https://github.com/python/cpython/blob/42fee931d055a3ef8ed31abe44603b9b2856e04d/Objects/object.c#L661-L713 Kind regards, Sam Ezeh On Fri, 6 May 2022 at 18:12, Jonathan Kaczynski wrote: > > Hi, > > I was recently trying to explain how python equality works and ran into a > gap in my knowledge. I haven't found any good pages going beneath a surface > level explanation of python equality comparison. > > I'll post my investigations below. What I think I'm looking for is where in > the source code (https://github.com/python/cpython) does the equality > comparison occur. I have an idea but wanted to ask first. > > > Using the dis module, we see the comparison operator is a single bytecode, > which is expected. > > ❯ docker run -it --rm ubuntu:jammy > root@919d94c98191:/# apt-get update > root@919d94c98191:/# apt-get --yes install python3 > root@919d94c98191:/# cat >play.py < import dis > import uuid > > def test(): > x = uuid.uuid4() > y = str(x) > x == y > return > > dis.dis(test) > EOF > root@f33b02fef026:/# python3 play.py > ... snip ... > 7 16 LOAD_FAST0 (x) > 18 LOAD_FAST1 (y) > 20 COMPARE_OP 2 (==) > 22 POP_TOP > ... snip ... > > > Stepping through the code with gdb, we see it jump from the compare > operator to the dunder-eq method on the UUID object. What I want to be able > to do is explain the in-between steps. Also, if you change `x == y` to `y > == x`, you still see the same behavior, which I assume has to do with > dunder-eq being defined on the UUID class and thus given priority. > > ❯ docker run -it --rm ubuntu:jammy > root@919d94c98191:/# apt-get update > root@919d94c98191:/# apt-get --yes install dpkg-source-gitarchive > root@919d94c98191:/# sed -i 's/^# deb-src/deb-src/' /etc/apt/sources.list > root@919d94c98191:/# apt-get update > root@919d94c98191:/# apt-get --yes install gdb python3.10-dbg > root@919d94c98191:/# apt-get source python3.10-dbg > root@919d94c98191:/# cat >play.py < import uuid > x = uuid.uuid4() > y = str(x) > breakpoint() > x == y > EOF > root@919d94c98191:/# gdb python3.10-dbg > (gdb) dir python3.10-3.10.4/Python > (gdb) run play.py > Starting program: /usr/bin/python3.10-dbg play.py > > warning: Error disabling address space randomization: Operation not > permitted > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > > //play.py(5)() > -> x == y > (Pdb) s > --Call-- > > /usr/lib/python3.10/uuid.py(239)__eq__() > -> def __eq__(self, other): > > > Thank you, > Jonathan > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Do projects exist to audit PyPI-hosted packages?
-- Forwarded message - From: Sam Ezeh Date: Fri, 6 May 2022, 15:29 Subject: Re: Do projects exist to audit PyPI-hosted packages? To: Skip Montanaro I've had similar thoughts in the past. I don't know of anything but I wonder if repositiories for other languages might have something to deal with it. A related problem is that even if a package is maintained by somebody with good intentions, the account might be hijacked by a malicious actor and since PyPi is separate from source control, people might not be able to find out easily and malware could spread through PyPi. Kind regards, Sam Ezeh On Fri, 6 May 2022, 14:08 Skip Montanaro, wrote: > I woke with a start in what amounted to the middle of the night (I really > need to get about three more hours of sleep, but you'll understand why I > was awake to write this). > > Many years ago, so as to preserve my wrists, I wrote a tool > <https://github.com/smontanaro/python-bits/blob/main/src/watch.py> to > monitor mouse and keyboard activity. It tells me when to rest. I use it > when I have problems, then put it away until it's needed again. I have > resurrected it a few times over the years, most recently a month or two > ago. Having never been all that fond of how I tracked keyboard and mouse > activity, I was happy when I stumbled upon pynput > <https://pypi.org/project/pynput/>. "Yay!", I thought. My worries are > over. > > Then extremely early this morning I woke thinking, "Damn, this runs on my > computer and it can see my mouse and keyboard activity. How do I know it's > not stealing my keystrokes?" Not going back to sleep after that. So, I'm > going through the code (and the Xlib package on which it relies) to make > myself more comfortable that there are no issues. Note: I am *most > certainly not* accusing the pynput author of any mischief. In fact, I > suspect there's no problem with the package. It's got a bunch of stars and > plenty of forks on GitHub (for what that's worth). I suspect the code has > had plenty of eyeballs looking at it. Still, I don't really know how well > vetted it might be, so I have no assurances of that. I saw it mentioned > somewhere (discuss I think?), checked it out, and thought it would solve my > activity tracking in a cross-platform way. (I currently only use an Xorg > environment, so while I am looking at the code, I'm not paying attention to > the Windows or MacOS bits either.) > > This got me thinking. If I'm curious about pynput, might other people be as > well? What about other packages? I'm actually not worried about Python > proper or vulnerabilities which have already been found > <https://github.com/pypa/advisory-database>. PyPI currently advertises > that > it hosts over 373k packages. With that many hosted packages, it is almost > certainly a haven for some undetected vulnerabilities. Knowing which > packages have been audited — at least in a cursory fashion — could be used > as a further criterion to use when deciding which packages to consider > using on a project. > > So, does something already exist (pointers appreciated)? Thx... > > Skip > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Why no list as dict key?
Repeating the above points, here is an example of what would happen if
you tried. Dictionaries require their keys to be immutable as
under-the-hood they use hash tables and they'd fail when the
underlying values are allowed to change.
```
[sam@samtop]: ~>$ python
Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import functools
>>> import operator
>>> class HashableList(list):
... def __hash__(self):
... return functools.reduce(operator.xor, [key * value for
key, value in enumerate(self)], 5)
...
>>> x = HashableList([1,2,3])
>>> y = HashableList([1,2,3])
>>> dictionary = {x: 5}
>>> dictionary
{[1, 2, 3]: 5}
>>> dictionary[x]
5
>>> dictionary[y]
5
>>> x.append(4)
>>> dictionary
{[1, 2, 3, 4]: 5}
>>> dictionary[x]
Traceback (most recent call last):
File "", line 1, in
KeyError: [1, 2, 3, 4]
>>> dictionary[y]
Traceback (most recent call last):
File "", line 1, in
KeyError: [1, 2, 3]
>>>
```
On Wed, 20 Apr 2022 at 19:23, Abdur-Rahmaan Janhangeer
wrote:
>
> Greetings list,
>
> Using Python3.9, i cannot assign a list [1, 2] as key
> to a dictionary. Why is that so? Thanks in advanced!
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about <https://compileralchemy.github.io/> | blog
> <https://www.pythonkitchen.com>
> github <https://github.com/Abdur-RahmaanJ>
> Mauritius
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: Tuple unpacking inside lambda expressions
I went back to the code recently and I remembered what the problem was. I was using multiprocessing.Pool.pmap which takes a callable (the lambda here) so I wasn't able to use comprehensions or starmap Is there anything for situations like these? Kind Regards, Sam Ezeh On Sat, 16 Apr 2022 at 22:36, Sam Ezeh wrote: > > Two questions here. > > Firstly, does anybody know of existing discussions (e.g. on here or on > python-ideas) relating to unpacking inside lambda expressions? > > I found myself wanting to write the following. > > ``` > map( > lambda (module, data): result.process(module, data), > jobs > ) > ``` > However, it's of course not legal Python syntax. > > The following were potential options but I felt they removed some of > the meaning from the code, making it less understandable for other > people. > > ``` > map( > lambda job: result.process(job[0], job[1]), > jobs > ) > ``` > > ``` > map( > lambda job: result.process(*job), > jobs > ) > ``` > > Secondly, for situations like these, do you have any go-to methods of > rewriting these while maintaining clarity? > > Kind Regards, > Sam Ezeh -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuple unpacking inside lambda expressions
This also works great! Kind Regards, Sam Ezeh On Tue, 19 Apr 2022 at 12:03, Antoon Pardon wrote: > > Op 16/04/2022 om 23:36 schreef Sam Ezeh: > > Two questions here. > > > > Firstly, does anybody know of existing discussions (e.g. on here or on > > python-ideas) relating to unpacking inside lambda expressions? > > > > I found myself wanting to write the following. > > > > ``` > > map( > > lambda (module, data): result.process(module, data), > > jobs > > ) > > ``` > > However, it's of course not legal Python syntax. > > Why not write: > > itertools.starmap(result.process, jobs) > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Enums and nested classes
Hello everyone, Has anyone here used or attempted to use a nested class inside an enum? If so, how did you find it? (what did you expect to happen and did your expectations align with resulting behaviour etc.) Here are two examples describing the situation I'm talking about ``` class Outer(Enum): a = 1 b = 2 class Inner(Enum): foo = 10 bar = 11 ``` ``` class Outer(Enum): a = 1 b = 2 class Inner: c = None def __init__(self): ``` Kind Regards, Sam Ezeh -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposal: Syntax for attribute initialisation in __init__ methods
I'll see if I can find out how positional only and keyword only arguments are used in __init__ methods in the wild and I'll see if there have been any other discussions talking about what this approach could offer. On Sun, 17 Apr 2022 at 02:54, dn wrote: > > On 17/04/2022 09.20, Sam Ezeh wrote: > >> Perhaps I'm missing the point, but what functionality or advantage(s) > >> does this give, over data-classes? > > > > One advantage is maintaining control over the __init__ function without > > having to write extra code to do so. In the linked discussion from > > python-ideas, it was mentioned that keyword-only and positional-only > > arguments can't be used with dataclasses [1]. > > > >> Maybe Dataclasses are not being used as much as one might hope, but they > >> are relatively new, and many Python-Masters simply carry-on constructing > >> classes the way they have for years... > > > > I think one concern I have is that even if this is useful, it might > > still fall to the same fate. > > > Don't be discouraged by that - and that thread was not the first of such > discussions! The way Python is being applied is continually changing... > > I'm not sure about the criticism of dataclasses though. Starting with > 'explicit over implicit', once a parameter-list is more than two or > three long, shouldn't we be using 'labels' in order to avoid (potential) > confusion, ie keyword-parameters? > > This removes the order/sequence of arguments from the list of potential > problems/gotchas one can fall into! > > In which case, I'm wondering just how often the criticism applies 'in > real life'? > > So, now the question becomes: what are the cases/examples which > require/desire improvement over the 'traditional' __init__ of > attributes, and facilities offered through dataclasses? > -- > Regards, > =dn > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Tuple unpacking inside lambda expressions
> In general, if you're using map() with a lambda function, it's often simpler to switch to a comprehension. Oh, of course, completely went past my head. > [result.process(module, data) for module, data in jobs] And this works great, thanks! On Sat, 16 Apr 2022 at 22:42, Chris Angelico wrote: > > On Sun, 17 Apr 2022 at 07:37, Sam Ezeh wrote: > > > > Two questions here. > > > > Firstly, does anybody know of existing discussions (e.g. on here or on > > python-ideas) relating to unpacking inside lambda expressions? > > > > I found myself wanting to write the following. > > > > ``` > > map( > > lambda (module, data): result.process(module, data), > > jobs > > ) > > ``` > > However, it's of course not legal Python syntax. > > What about: > > [result.process(module, data) for module, data in jobs] > > (or with () instead of [] around the outside if you want a generator)? > > In general, if you're using map() with a lambda function, it's often > simpler to switch to a comprehension. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Proposal: Syntax for attribute initialisation in __init__ methods
I've just seen Pablo's very recent post on python-ideas so I thought I'd link it here. [1] [1]: https://mail.python.org/archives/list/python-id...@python.org/message/SCXHEWCHBJN3A7DPGGPPFLSTMBLLAOTX/ Kind Regards, Sam Ezeh On Fri, 15 Apr 2022 at 22:57, Ethan Furman wrote: > > On 4/15/22 04:19, Sam Ezeh wrote: > > Elsewhere, the idea of supporting new syntax to automatically initialise > > attributes provided as arguments to __init__ methods was raised. > > [...] > > Good post! You'll want to send this to python-ideas at some point (that's > where most new python features are > discussed). This particular desire has come up in the past, so you'll need > to do some more research (i.e. find the > previous threads on python-ideas) so you can answer objections already > raised, or find new data supporting/refuting > previous arguments. > > -- > ~Ethan~ > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Fwd: Proposal: Syntax for attribute initialisation in __init__ methods
> Perhaps I'm missing the point, but what functionality or advantage(s) > does this give, over data-classes? One advantage is maintaining control over the __init__ function without having to write extra code to do so. In the linked discussion from python-ideas, it was mentioned that keyword-only and positional-only arguments can't be used with dataclasses [1]. > Maybe Dataclasses are not being used as much as one might hope, but they > are relatively new, and many Python-Masters simply carry-on constructing > classes the way they have for years... I think one concern I have is that even if this is useful, it might still fall to the same fate. [1]: https://mail.python.org/archives/list/python-id...@python.org/message/SCTXSEKOWDRDGVXXOEB7JUC6WE7XKGMO/ On Fri, 15 Apr 2022 at 22:30, dn wrote: > > On 15/04/2022 23.19, Sam Ezeh wrote: > ... > > Kudos for doing the research! > > > > Some related implementations are attrs, dataclasses and the use of a > > decorator. And there's potentially a point to be raised that the results > > from the first query indicate that the @dataclasse decorator is not being > > used enough. One advantage this proposal offers is control over the > > arguments that the __init__ function takes. > > > > A downside to using a decorator is that it might become difficult to accept > > arguments that don't need to be assigned to anything. > > > > I gave the example of the following code (unlike the above, this is not > > taken from existing python source code). In this example, a decorator can't > > assign all of the arguments to attributes or else it would produce code > > that does something different. > ... > > > I will support anything which reduces 'boiler-plate' or 'make busy' work! > > Perhaps I'm missing the point, but what functionality or advantage(s) > does this give, over data-classes? > > Maybe Dataclasses are not being used as much as one might hope, but they > are relatively new, and many Python-Masters simply carry-on constructing > classes the way they have for years... > > If data-classes give the impression of being 'syntactic sugar', there's > no particular need to use them - and certainly no rule or demand. > > There are constructs where one might find it easier not to use them. > > @dataclass does allow init=False. > > There is an argument which says that all data-attributes should be > 'created' inside an __init__() or __post_init__(), rather than > 'somewhere', 'later'. > -- > Regards, > =dn > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Tuple unpacking inside lambda expressions
Two questions here. Firstly, does anybody know of existing discussions (e.g. on here or on python-ideas) relating to unpacking inside lambda expressions? I found myself wanting to write the following. ``` map( lambda (module, data): result.process(module, data), jobs ) ``` However, it's of course not legal Python syntax. The following were potential options but I felt they removed some of the meaning from the code, making it less understandable for other people. ``` map( lambda job: result.process(job[0], job[1]), jobs ) ``` ``` map( lambda job: result.process(*job), jobs ) ``` Secondly, for situations like these, do you have any go-to methods of rewriting these while maintaining clarity? Kind Regards, Sam Ezeh -- https://mail.python.org/mailman/listinfo/python-list
Proposal: Syntax for attribute initialisation in __init__ methods
Elsewhere, the idea of supporting new syntax to automatically initialise
attributes provided as arguments to __init__ methods was raised.
Very often, __init__ functions will take arguments only to assign them as
attributes of self. This proposal would remove the need to additionally
write `self.argument = argument` when doing this.
I'm specifically looking at statements of the form `self.argument =
argument`.
I ran a query on the source code of the top 20 most downloaded PyPi
packages (source:
https://github.com/dignissimus/presearch/blob/master/queries/attribute_initialisation.py)
and found the following statistics. I found that 19% of classes that define
__init__ and have at least one argument that isn't `self` assign all of
those non-self arguments as attributes with the same name in the function
definition.
I also found that 33% of __init__ functions that have more than one
non-self argument assign at least one of their arguments as attributes with
the same name, that 27% of __init__ functions that have at least two
non-self arguments assign at least 2 of them as attributes with the same
name and that 28% of __init__ functions that had 3 or more non-self
arguments assigned at least 3 of their arguments as attributes with the
same name.
```
[sam@samtop]: ~/Documents/git/presearch>$ presearch -f
queries/attribute_initialisation.py sources/
Running queries...
Out of 1526 classes defining __init__, there were 290 (19.0%) classes whose
__init__ functions assigned all non-self arguments as attributes.
Out of 1526 __init__ functions with at least one non-self argument, there
were 497 (32.57%) __init__ functions that assigned one or more non-self
arguments as attributes.
Out of 834 __init__ functions with at least two non-self arguments, there
were 221 (26.5%) __init__ functions that assigned two or more non-self
arguments as attributes.
Out of 490 __init__ functions with at least three non-self arguments, there
were 139 (28.37%) __init__ functions that assigned three or more non-self
arguments as attributes.
[sam@samtop]: ~/Documents/git/presearch>$
```
With the new syntax, the following snippet taking from the pyyaml source
code (pyyaml is the 12th most downloaded package this month on PyPi)
```
def __init__(self, default_style=None, default_flow_style=False,
sort_keys=True):
self.default_style = default_style
self.sort_keys = sort_keys
self.default_flow_style = default_flow_style
self.represented_objects = {}
self.object_keeper = []
self.alias_key = None
```
Can be re-written as follows
```
def __init__(self, @default_style=None, @default_flow_style=False,
@sort_keys=True):
self.represented_objects = {}
self.object_keeper = []
self.alias_key = None
```
And from numpy, the following code
```
def __init__(self, mbfunc, fillx=0, filly=0):
"""
abfunc(fillx, filly) must be defined.
abfunc(x, filly) = x for all x to enable reduce.
"""
super().__init__(mbfunc)
self.fillx = fillx
self.filly = filly
ufunc_domain[mbfunc] = None
ufunc_fills[mbfunc] = (fillx, filly)
```
Can be written like this
```
def __init__(self, mbfunc, @fillx=0, @filly=0):
"""
abfunc(fillx, filly) must be defined.
abfunc(x, filly) = x for all x to enable reduce.
"""
super().__init__(mbfunc)
ufunc_domain[mbfunc] = None
ufunc_fills[mbfunc] = (fillx, filly)
```
Some related implementations are attrs, dataclasses and the use of a
decorator. And there's potentially a point to be raised that the results
from the first query indicate that the @dataclasse decorator is not being
used enough. One advantage this proposal offers is control over the
arguments that the __init__ function takes.
A downside to using a decorator is that it might become difficult to accept
arguments that don't need to be assigned to anything.
I gave the example of the following code (unlike the above, this is not
taken from existing python source code). In this example, a decorator can't
assign all of the arguments to attributes or else it would produce code
that does something different.
```
class ExampleClass:
def __init__(self, example, argument, word):
self.example = example
self.argument = argument
do_something(word)
```
In response, the following was given
```
class ExampleClass:
@make_attr("example")
@make_attr("argument")
def __init__(self, example, argument, word):
do_something(word)
```
And this could potentially be written like this
```
class ExampleClass:
@make_attr("example", "argument")
def __init__(self, example, argument, word):
do_something(word)
```
However, having to rewrite the argument name might defeat the purpose of
having a decorator.
As an idea, I thought about the case of when an __init__ method
Re: Functionality like local static in C
I've seen people use function attributes for this. ``` Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> def function(): ... print(function.variable) ... function.variable += 1 ... >>> function.variable = 1 >>> function() 1 >>> function() 2 >>> ``` If necessary, the variable can be initialised inside the function too. Kind Regards, Sam Ezeh On Thu, 14 Apr 2022 at 16:36, Sam Ezeh wrote: > > I've seen people use function attributes for this. > ``` > Python 3.10.2 (main, Jan 15 2022, 19:56:27) [GCC 11.1.0] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> def function(): > ... print(function.variable) > ... function.variable += 1 > ... > >>> function.variable = 1 > >>> function() > 1 > >>> function() > 2 > >>> > ``` > > If necessary, the variable can be initialised inside the function too. > > Kind Regards, > Sam Ezeh > > > On Thu, 14 Apr 2022 at 16:26, Cecil Westerhof via Python-list > wrote: > > > > In C when you declare a variable static in a function, the variable > > retains its value between function calls. > > The first time the function is called it has the default value (0 for > > an int). > > But when the function changes the value in a call (for example to 43), > > the next time the function is called the variable does not have the > > default value, but the value it had when the function returned. > > Does python has something like that? > > > > -- > > Cecil Westerhof > > Senior Software Engineer > > LinkedIn: http://www.linkedin.com/in/cecilwesterhof > > -- > > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
[issue47184] multiprocessing.set_start_method force argument is not documented
Sam Ezeh added the comment: It's quite weird, the documentation says set_start_method "should not be used more than once in the program" twice. The source code also contains the following line ``` # Type of default context -- underlying context can be set at most once ``` I'm not too familiar with the multiprocessing library but with the force parameter set to True, I don't understand why that can't happen. If there's a specific reason, maybe that should be documented too. -- ___ Python tracker <https://bugs.python.org/issue47184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47184] multiprocessing.set_start_method force argument is not documented
Change by Sam Ezeh : -- keywords: +patch nosy: +sam_ezeh nosy_count: 2.0 -> 3.0 pull_requests: +30395 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32339 ___ Python tracker <https://bugs.python.org/issue47184> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Sam Ezeh added the comment: I don't know what the best course of action would be but if preserving permissions needs to be back-ported, could the default permission preservation flag in 3.11+ be the one to preserve safe permissions and then make it so that the previous versions (<3.11, without the constants) always take this course of action? Maintaining the different options for preserving permissions while still allowing for this functionality to be back-ported. I don't have a strong opinion on backporting permission preservation but to me, it seems like it would be a change in behaviour instead of a bug fix. The current default in the PR is to not preserve any permissions but if necessary, I'll change it to whatever is agreed upon. I'll move the constants into an enum, but right now I'm not sure how I'd name the class. As an aside, while writing this comment I realised that the reason tests aren't passing on my end might very well be due to the fact I do CPython work on an NTFS partition instead of on my main EXT4 partition. -- ___ Python tracker <https://bugs.python.org/issue15795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30964] Mention ensurepip in package installation docs
Change by Sam Ezeh : -- pull_requests: -30352 ___ Python tracker <https://bugs.python.org/issue30964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Change by Sam Ezeh : -- pull_requests: +30353 pull_request: https://github.com/python/cpython/pull/32291 ___ Python tracker <https://bugs.python.org/issue39064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30964] Mention ensurepip in package installation docs
Change by Sam Ezeh : -- nosy: +sam_ezeh nosy_count: 3.0 -> 4.0 pull_requests: +30352 pull_request: https://github.com/python/cpython/pull/32291 ___ Python tracker <https://bugs.python.org/issue30964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Sam Ezeh added the comment: Yes, of course. -- ___ Python tracker <https://bugs.python.org/issue39064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Sam Ezeh added the comment:
One way of doing this is by making the central directory offset negative by
first taking the zip file containing just an EOCD record and then listing the
total size of the central directory records as positive.
```
Python 3.11.0a4+ (heads/bpo-39064:eb1935dacf, Apr 3 2022, 19:09:53) [GCC
11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> import io
>>> b = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> b[12] = 1
>>> f = io.BytesIO(bytes(b))
>>> zipfile.ZipFile(f)
Traceback (most recent call last):
File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1370, in
_RealGetContents
fp.seek(self.start_dir, 0)
^^
ValueError: negative seek value -1
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 1, in
File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1284, in __init__
self._RealGetContents()
^^^
File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1372, in
_RealGetContents
raise BadZipFile("Bad offset for central directory")
zipfile.BadZipFile: Bad offset for central directory
>>>
```
--
___
Python tracker
<https://bugs.python.org/issue39064>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39064] ValueError in zipfile.ZipFile
Change by Sam Ezeh : -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue39064> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Change by Sam Ezeh : -- pull_requests: +30350 pull_request: https://github.com/python/cpython/pull/32289 ___ Python tracker <https://bugs.python.org/issue15795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15795] Zipfile.extractall does not preserve file permissions
Change by Sam Ezeh : -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue15795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47200] Add ZipInfo.mode property
Change by Sam Ezeh : -- pull_requests: +30323 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32252 ___ Python tracker <https://bugs.python.org/issue47200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47200] Add ZipInfo.mode property
New submission from Sam Ezeh : Initially, I was looking at bpo-18262 and saw the following Stack Overflow thread that was linked. https://stackoverflow.com/questions/434641/how-do-i-set-permissions-attributes-on-a-file-in-a-zip-file-using-pythons-zip/6297838 I've attached a patch that gives ZipInfo objects a `ZipInfo.mode` property getter and setter to get and set the file mode. I considered adding ZipFile.chmod but I didn't know how it would work given that archives can contain duplicate files. As an aside, I wondered if there's a way to update file attributes inside zip archives without deleting and rewriting them and if not, whether it would be worthwhile to add one. -- components: Library (Lib) files: sam_ezeh.patch keywords: patch messages: 416550 nosy: sam_ezeh priority: normal severity: normal status: open title: Add ZipInfo.mode property type: enhancement versions: Python 3.11 Added file: https://bugs.python.org/file50715/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue47200> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Change by Sam Ezeh : -- pull_requests: +30313 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32242 ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Sam Ezeh added the comment: This is what functionality looks like when supplying incorrect attribute names with the patch. Python 3.11.0a6+ (heads/bpo-47135-dirty:d4bb38f82b, Apr 1 2022, 20:01:56) [GCC 11.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import _pydecimal >>> ctx = _pydecimal.getcontext() >>> ctx.precision = 10 Traceback (most recent call last): File "", line 1, in File "/run/media/sam/OS/Git/cpython/Lib/_pydecimal.py", line 3974, in __setattr__ raise AttributeError( ^ AttributeError: 'decimal.Context' object has no attribute 'precision' >>> with _pydecimal.localcontext(precision=10) as ctx: ... pass ... Traceback (most recent call last): File "", line 1, in File "/run/media/sam/OS/Git/cpython/Lib/_pydecimal.py", line 506, in localcontext setattr(ctx, key, value) File "/run/media/sam/OS/Git/cpython/Lib/_pydecimal.py", line 3974, in __setattr__ raise AttributeError( ^ AttributeError: 'decimal.Context' object has no attribute 'precision' >>> import decimal >>> ctx = decimal.getcontext() >>> ctx.precision = 10 Traceback (most recent call last): File "", line 1, in AttributeError: 'decimal.Context' object has no attribute 'precision' >>> with decimal.localcontext(precision=10) as ctx: ... pass ... Traceback (most recent call last): File "", line 1, in TypeError: 'precision' is an invalid keyword argument for this function >>> -- ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Sam Ezeh added the comment: I've uploaded a patch and it seems to work, which I'm very proud of. I'll create some tests, amend documentation and create a news entry. After that, I'll create a pull request on GitHub. -- keywords: +patch Added file: https://bugs.python.org/file50713/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Sam Ezeh added the comment: I'm looking into adding this > Seems reasonable to me, but I think a full implementation would want to throw > an error for keyword args that don't already exist as context attributes > (otherwise typos would fail silently) For _pydecimal, I think this would automatically happen automatically as Context.__setattr__ raises AttributeError when it's passed a name that isn't a context attribute. For _decimal this can be done with keyword arguments and `PyArg_ParseTupleAndKeywords`. -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : -- pull_requests: +30300 stage: -> patch review pull_request: https://github.com/python/cpython/pull/32225 ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Added file: https://bugs.python.org/file50711/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Removed file: https://bugs.python.org/file50710/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Added file: https://bugs.python.org/file50710/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Change by Sam Ezeh : Removed file: https://bugs.python.org/file50709/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32547] csv.DictWriter emits strange errors if fieldnames is an iterator
Sam Ezeh added the comment: I've submitted a patch that introduces code that raises TypeError at construction if `fieldnames` is not a sequence -- keywords: +patch nosy: +sam_ezeh Added file: https://bugs.python.org/file50709/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue32547> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Sam Ezeh added the comment: I've submitted the above patch. I created the ZipFile.mkdir function, created the necessary tests and wrote the documentation. I think it is ready for review. -- Added file: https://bugs.python.org/file50705/sam_ezeh.patch ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Change by Sam Ezeh : -- keywords: +patch pull_requests: +30238 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/32160 ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Sam Ezeh added the comment: I'm looking into adding ZipFile.mkdir -- ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
Change by Sam Ezeh : -- nosy: +sam_ezeh ___ Python tracker <https://bugs.python.org/issue4833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14265] Fully qualified test name in failure output
Sam Ezeh added the comment: The provided patch wasn't entirely compatible with the current upstream code. I used the patch file to apply the changes to `Lib/unittest/case.py`, resolved the remaining conflicts with the patches to the test files and amended existing tests for the library. I updated the documentation for unittest to reflect the changes in behaviour. -- ___ Python tracker <https://bugs.python.org/issue14265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14265] Fully qualified test name in failure output
Change by Sam Ezeh : -- keywords: +patch pull_requests: +30218 pull_request: https://github.com/python/cpython/pull/32138 ___ Python tracker <https://bugs.python.org/issue14265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14265] Fully qualified test name in failure output
Change by Sam Ezeh : -- nosy: +dignissimus ___ Python tracker <https://bugs.python.org/issue14265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Sam Bull added the comment: There is still an issue here. I proposed a possible solution at: https://github.com/python/cpython/pull/28149#issuecomment-1007823782 You can also scroll up through the lengthy discussion to see how I reached that conclusion. I've not had time yet to actually try implementing something yet. -- ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > We could store the nonces in a single CancelledError instead. Indeed, my initial proposal was exactly that, but after learning about ExceptionGroup, I thought that was a cleaner approach. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > Previously, when the task was cancelled twice, only one CancelledError was > raised. Now it would raise a BaseExceptionGroup instead. I was under the impression that ExceptionGroup was somewhat backwards compatible, in that you could still use `except CancelledError:` and it would catch all the errors in the group. But, maybe I'm wrong, I've not seen the documentation for the final feature yet, but that's the impression I got from the PEP. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: Actually, in your counter proposal, you say: > Such context managers should still keep track of whether they cancelled the > task themselves or not, and if they did, they should always call t.uncancel(). But, if we are using nonces on the CancelledError to keep track, then only 1 context manager will know if it was themselves or not. This is exactly why I'm proposing to use multiple CancelledErrors, so that every nonce is passed to the handling code. -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > This should be solved when using the cancel count -- the explicit cancel > bumps the cancel count so the cancel scope (i.e. timeout()) will not raise > TimeoutError. It will probably work in this case. But, what about more complex cases? If there are 2 different timeouts and the possibility of a user cancellation, and we have a count of 2 cancellations, then what happened? 2 timeouts, or 1 timeout and user cancellation? Without being able to check the nonces of each cancellation, I don't see how this would work. Or if the user calls .cancel() twice explicitly, then you cancel both timeouts, even though it had nothing to do with the timeout. Propagating an ExceptionGroup where every exception can be inspected to see if it was caused by this code or not still seems like the safe option to me (and obviously still has the cancel count implicitly). -- ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46771] Add some form of cancel scopes
Sam Bull added the comment: > If the task is already pending a cancellation targeted at a cancel scope, the > task itself cannot be cancelled anymore since calling cancel() again on the > task is a no-op. This would be solved by updating the cancel message on the > second call. > I think Andrew missed one case: in his second diagram, what if the explicit > cancel() happened *after* the timeout (but still in the same iteration)? > That's the case that makes me want to delete those two lines from > Task.cancel() (see my earlier message). To expand on this point, I've been looking at solving the race conditions in async-timeout. To see how such a race condition can end up with a task never exiting, take a look at this example: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 In the condition Guido describes, the user's cancellation is suppressed and the code runs forever. I also wrote tests that seem to reliably reproduce the race condition (the 2nd one still seems unfixable with the current solutions, the 1st was fixed with the nonce/sentinel trick): https://github.com/aio-libs/async-timeout/commit/ab04eb53dcf49388b6e6eacf0a50bafe19c5c74b#diff-60a009a48129ae41018d588c32a6d94c54d1d2948cbc3b831fc27a9c8fdbac68L364-L421 You can see the flow of execution from the call_order assert at the end. I think most of the solutions proposed here will still not solve this race condition. I initially proposed a solution at: https://bugs.python.org/issue45098 In short, I think that every time we call .cancel(), we need to raise another CancelledError. So, in this race condition you would get 2 CancelledErrors (via an ExceptionGroup). Then our code can catch the error with our nonce/sentinel and handle that, but also reraise any other errors which are unrelated. -- nosy: +dreamsorcerer ___ Python tracker <https://bugs.python.org/issue46771> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45098] asyncio.CancelledError should contain more information on cancellations
Sam Bull added the comment: I think there's still a problem, in that the user still expects a task to be cancelled in the example previously: https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 If we encounter the race condition where the timeout cancels the task and then the user cancels the task, then we still have the case that async-timeout swallows the cancellation and the task will run forever. This would basically require the user to check everytime they want to cancel the task, with something awkward like: ``` while not task.cancel() and not task.cancelled(): await asyncio.sleep(0) ``` I think this change is still necessary, but rather than adding multiple values to e.args, we can use the new ExceptionGroup to raise multiple CancelledErrors. So, each call of task.cancel() will create a new CancelledError, and then all of those CancelledErrors will get raised together. For async-timeout, we can then just catch the CancelledError with our sentinel and raise a TimeoutError, while reraising any other CancelledErrors. -- ___ Python tracker <https://bugs.python.org/issue45098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.timestamp() fails for naive-datetime values prior to the start of the epoch
Change by Sam Roberts : -- resolution: -> not a bug ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.timestamp() fails for naive-datetime values prior to the start of the epoch
Sam Roberts added the comment: this seems like an expected discrepancy because of a difference in the mechanism used for aware datatimes vs. naive datetimes, although I'm not sure I understand why the computation with naive datetimes uses the mktime() function rather than invoking datetime.timedelta.total_seconds() on a datetime difference. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.timestamp() fails for naive-datetime values prior to the start of the epoch
Sam Roberts added the comment: the first sentence should have read: datetime.timestamp() fails for naive-datetime values prior to the start of the epoch, but for some reason works properly for aware-datetime values prior to the start of the epoch. -- title: datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch -> datetime.timestamp() fails for naive-datetime values prior to the start of the epoch ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch
Change by Sam Roberts : -- title: datetime.datetime.fromtimestamp -> datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46660] datetime.datetime.fromtimestamp
New submission from Sam Roberts : Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC v.1928 64 bit (AMD64)] on win32 datetime.fromtimestamp() fails for naive-datetime values prior to the start of the epoch, but for some reason works properly for aware-datetime values prior to the start of the epoch. This is at least inconsistent, but seems like a bug. Negative timestamps for dates prior to the start of the epoch are used by yahoo finance and in the yfinance module. >>> import datetime >>> start = int(datetime.datetime(1962, 1, 31, >>> tzinfo=datetime.timezone.utc).timestamp()) >>> start -249868800 >>> start = int(datetime.datetime(1962, 1, 31).timestamp()) Traceback (most recent call last): File "", line 1, in start = int(datetime.datetime(1962, 1, 31).timestamp()) OSError: [Errno 22] Invalid argument -- components: Library (Lib) messages: 412649 nosy: smrpy priority: normal severity: normal status: open title: datetime.datetime.fromtimestamp type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue46660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38633] shutil.copystat fails with PermissionError in WSL
Sam Park added the comment: FWIW I just ran into this today on Ubuntu 18.04 container on GKE 1.21.5-gke.1302 and on a Ubuntu-with-Docker underlying node (if that's relevant). Applying the monkeypatch solves the issue as well. -- nosy: +sam.park ___ Python tracker <https://bugs.python.org/issue38633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] test.libregrtest: Race condition in runtest_mp leads to hangs (never exits)
Change by Sam Gross : -- keywords: +patch pull_requests: +28673 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30470 ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] Race condition in runtest_mp leads to hangs (never exits)
Change by Sam Gross : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] Race condition in runtest_mp leads to hangs (never exits)
Change by Sam Gross : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46205] Race condition in runtest_mp leads to hangs (never exits)
New submission from Sam Gross : The runtest_mp.py has a race condition between checking for worker.is_alive() and processing the queue that can lead to indefinite hangs. The hang happens when the all the results from the self.output queue are processed but at least one of the workers hasn't finished exiting. https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/test/libregrtest/runtest_mp.py#L394-L418 The main thread tries to get a result from the output queue, but the queue is empty and remains empty. Although the queue.get() operation eventually times out (after 30 seconds), the main thread does not re-check if all the workers have exited (!), but instead retries the queue.get() in the "while True" loop. https://github.com/python/cpython/blob/8d7644fa64213207b8dc6f555cb8a02bfabeced2/Lib/test/libregrtest/runtest_mp.py#L415-L418 To reproduce, apply the below patch which introduces a small delay to more reliably trigger the hang. curl "https://gist.githubusercontent.com/colesbury/fe3769f43dfb724c86ecbb182b1f6749/raw/e29a4eaeebb8d5252cdd66f3f8a70f7bc5fa14e7/runtest_mp.diff; | patch -p1 ./python -m test test_regrtest -m test_module_from_test_autotest -v -- messages: 409374 nosy: colesbury priority: normal severity: normal status: open title: Race condition in runtest_mp leads to hangs (never exits) versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
Sam Bull added the comment: It has been addressed, PR should be merged this week: https://github.com/python/cpython/pull/28149 Like most open source projects, it just needed someone to actually propose a fix. -- ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45838] Incorrect line numbers in GDB Python backtraces [3.9]
Change by Sam Gross : -- keywords: +patch pull_requests: +27860 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29628 ___ Python tracker <https://bugs.python.org/issue45838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45838] Incorrect line numbers in GDB Python backtraces [3.9]
New submission from Sam Gross : Starting in Python 3.6 the line numbers table contains a *signed* byte indicating line delta. The calculation in Tools/gdb/libpython.py was not updated to handle signed bytes leading to incorrect line numbers when running "py-bt" (or printing frames) in GDB. This issue does not exist in Python 3.10 or later because line number table was changed (and libpython.py was updated) in GH-23113. -- components: Demos and Tools messages: 406560 nosy: colesbury priority: normal severity: normal status: open title: Incorrect line numbers in GDB Python backtraces [3.9] type: behavior versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45835] Race condition in test_queue can lead to test failures
Change by Sam Gross : -- pull_requests: +27844 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29601 ___ Python tracker <https://bugs.python.org/issue45835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45835] Race condition in test_queue can lead to test failures
Change by Sam Gross : -- keywords: +patch Added file: https://bugs.python.org/file50447/issue45835_repro.patch ___ Python tracker <https://bugs.python.org/issue45835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45835] Race condition in test_queue can lead to test failures
New submission from Sam Gross : The test_queue suite has a race condition that can lead to test failures in test_many_threads, test_many_threads_nonblock, and test_many_threads_timeout. Consumers are signaled to exit by a sentinel value (None). The sentinel values are at the end of the input list, but that doesn't mean they are necessarily enqueued at the end of the inter-thread queue when there are multiple "feeder" threads. In particular, a feeder thread may be delayed in enqueueing a non-sentinel value. The other feeder threads may finish popping and enqueueing the remaining values including all the sentinels, leading to the delayed non-sentinel value arriving AFTER all the sentinels. The "consumer" threads exit before processing all the values leading to the assertion error in run_threads() in test_queue.py: self.assertTrue(q.empty()) I will attach a patch that adds a delay in feed() to make the race condition occur more frequently so that the issue is easier to reproduce. -- components: Tests messages: 406498 nosy: colesbury priority: normal severity: normal status: open title: Race condition in test_queue can lead to test failures type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45835> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42540] Debug pymalloc crash when using os.fork() [regression]
Change by Sam Gross : -- pull_requests: +27843 pull_request: https://github.com/python/cpython/pull/29600 ___ Python tracker <https://bugs.python.org/issue42540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42969] pthread_exit & PyThread_exit_thread from PyEval_RestoreThread etc. are harmful
Sam Gross added the comment: The `pthread_exit` behavior has been a problem for PyTorch and related libraries since Python 3.9. The PyTorch team has tried working around the problems without success (i.e. they keep getting bug reports involving crashes in PyEval_SaveThread/RestoreThread). The hang/paused the thread behavior suggested by jbms and gps seems like the only reliable option. This is also what the Java VM does when returning from native code and the JVM has exited. I believe it's not difficult to hang a thread in a cross-platform way: create a mutex, acquire it in the main thread (before setting PyRuntime._finalizing), never release it. Other threads can acquire that same mutex to block until the application exits. The crashes can occur even without daemon threads if the user presses ctrl-c while _thread_shutdown is running. -- nosy: +colesbury ___ Python tracker <https://bugs.python.org/issue42969> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42540] Debug pymalloc crash when using os.fork() [regression]
Change by Sam Gross : -- keywords: +patch nosy: +colesbury nosy_count: 2.0 -> 3.0 pull_requests: +27812 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29564 ___ Python tracker <https://bugs.python.org/issue42540> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45809] Race condition in WeakKeyDictionary/WeakKeyDictionary
Sam Gross added the comment: The attached patch (issue45809-repro.patch) introduces artificial delays to make reproduction of the underlying issue easier. To reproduce the issue: patch -p1 < issue45809-repro.patch ./python -m test test_weakref -m test_threaded_weak_value_dict_deepcopy -v -- keywords: +patch Added file: https://bugs.python.org/file50440/issue45809-repro.patch ___ Python tracker <https://bugs.python.org/issue45809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45809] Race condition in WeakKeyDictionary/WeakKeyDictionary
New submission from Sam Gross : The issue described issue7105 (and maybe issue7060) still exists due to a race condition in WeakKeyDictionary. This shows up as test failure that looks like: test test_weakref failed -- Traceback (most recent call last): File "Lib/test/test_weakref.py", line 1960, in test_threaded_weak_value_dict_deepcopy self.check_threaded_weak_dict_copy(weakref.WeakValueDictionary, True) File "Lib/test/test_weakref.py", line 1940, in check_threaded_weak_dict_copy raise exc[0] File "Lib/test/test_weakref.py", line 1897, in dict_copy _ = copy.deepcopy(d) File "Lib/copy.py", line 153, in deepcopy y = copier(memo) File "Lib/weakref.py", line 189, in __deepcopy__ for key, wr in self.data.items(): RuntimeError: dictionary changed size during iteration The cause is that the check of "self._iterating" and the call to "_atomic_removal" are not performed atomically together. By the time _atomic_removal() is called, an iteration might have already started. https://github.com/python/cpython/blob/ec382fac0db6d9159c2d3496a70b7a605545957e/Lib/weakref.py#L109-L114 -- components: Library (Lib) messages: 406357 nosy: colesbury priority: normal severity: normal status: open title: Race condition in WeakKeyDictionary/WeakKeyDictionary type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45598] setup.py grep_headers_for() is broken by design
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45350] configure incorrectly ignores pkg-config information for libffi and Tcl/Tk in 3.10
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45350> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45643] SIGSTKFLT is missing from the signals module on Linux
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45643> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45256] Remove the usage of the C stack in Python to Python calls
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44525] Implement CALL_FUNCTION adaptive interpreter optimizations
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45484] test_pickle segfault on s390x RHEL7 LTO 3.x
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45668] Some PGO tests are failing when building with --enable-optimizations --disable-test-modules
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45668> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Change by Sam Gross : -- pull_requests: +27513 pull_request: https://github.com/python/cpython/pull/29249 ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Change by Sam Gross : -- keywords: +patch pull_requests: +27510 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29246 ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Sam Gross added the comment: Antoine Pitrou already fixed the "noddy4" example (now renamed to "custom4") and updated the newtypes_tutorial, but I think it's still worth mentioning PyObject_GC_Untrack in a few additional places. -- ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28737] Document that tp_dealloc handler must call PyObject_GC_UnTrack if Py_TPFLAGS_HAVE_GC is set
Change by Sam Gross : -- assignee: docs@python -> colesbury ___ Python tracker <https://bugs.python.org/issue28737> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Sam Bull added the comment: Can I get a review? https://github.com/python/cpython/pull/29202 Seems like a simple mistake given the original description of this issue: > 1. the inner task is completed and the outer task will receive the result – > transport and protocol in this case > 2. The inner task is cancelled and no connection was established The try/except blocks clearly add a 3rd condition, where the inner task is completed and a TimeoutError is raised without returning the result. -- ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37658] In some cases asyncio.wait_for can lead to socket leak.
Change by Sam Bull : -- nosy: +dreamsorcerer nosy_count: 10.0 -> 11.0 pull_requests: +27471 pull_request: https://github.com/python/cpython/pull/29202 ___ Python tracker <https://bugs.python.org/issue37658> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45433] libpython should not be linked with libcrypt
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue45433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45331] Can create enum of ranges, cannot create range enum. Range should be subclassable... or EnumMeta.__new__ should be smarter.
New submission from Sam Bishop : Range types are perfectly valid as values in an enum, like so. class EnumOfRanges(Enum): ZERO = range(0, 0) RANGE_A = range(1, 11) RANGE_B = range(11, 26) However unlike the other base types , 'int', 'str', 'float', etc. You cannot create a "range enum" class RangeEnum(range, Enum): ZERO = range(0, 0) RANGE_A = range(1, 11) RANGE_B = range(11, 26) produces `TypeError: type 'range' is not an acceptable base type` when you try and import `RangeEnum`. The current documentation for `enum` implicitly says this should work by not mentioning anything special here https://docs.python.org/3/library/enum.html#others It also allows the use of range objects as value types, another implicit suggestion that we should be able to restrict an enum class to just range values like we can for other builtin class types. Also to keep this a concise issue: - Yes I'm aware not all of the base classes can be subclassed. - Yes I know I that there are good reasons bool should not be subclassable. So I'd like to suggest one of three things should be done to improve the situation: A: Solve https://bugs.python.org/issue17279 and by documenting the special base class objects that cannot be subclassed and reference this in the documentation for Enums. B: Make a decision as to which base class objects we should be able to subclass, and then improve their C implementations to allow subclassing. (It's also probably worth documenting the final list of special objects and solving https://bugs.python.org/issue17279 should this approach be selected.) C: The __new__ method on EnumMeta should be made smarter so that it either emits a more useful warning (I had to head to the CPython source code to work out what the error `TypeError: type 'range' is not an acceptable base type` meant) or somehow being more smart about how it handles the special classes which can't cannot be subclassed allowing them to be used anyway. which again sort of involves solving https://bugs.python.org/issue17279, and in the case that its just made magically smarter, I'll admit could confuse some people as to why "Enum" is special and can subclass these but their own code can't just do `class MyRange(range):` Regardless of the outcome, it would be good to fill in this pitfall one way or the other for the sake of future developers, I'm a reasonably experienced Python developer and it caught me by surprise I'm likely not the first and probably wont be the last if the behaviour remains as it currently is. -- components: Interpreter Core messages: 402960 nosy: techdragon priority: normal severity: normal status: open title: Can create enum of ranges, cannot create range enum. Range should be subclassable... or EnumMeta.__new__ should be smarter. type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45331> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44751] crypt.h should be in _cryptmodule.c, not in public header
Change by Sam James : -- nosy: +thesamesam ___ Python tracker <https://bugs.python.org/issue44751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45098] asyncio.CancelledError should contain more information on cancellations
New submission from Sam Bull : There are awkward edge cases caused by race conditions when cancelling tasks which make it impossible to reliably cancel a task. For example, in the async-timeout library there appears to be no way to avoid suppressing an explicit t.cancel() if that cancellation occurs immediately after the timeout. In the alternative case where a cancellation happens immediately before the timeout, the solutions feel dependant on the internal details of how asynico.Task works and could easily break if the behaviour is tweaked in some way. What we really need to know is how many times a task was cancelled as a cause of the CancelledError and ideally were the cancellations caused by us. The solution I'd like to propose is that the args on the exception contain all the messages of every cancel() call leading up to that exception, rather than just the first one. e.g. In these race conditions e.args would look like (None, SENTINEL), where SENTINEL was sent in our own cancellations. From this we can see that the task was cancelled twice and only one was caused by us, therefore we don't want to suppress the CancelledError. For more details to fully understand the problem: https://github.com/aio-libs/async-timeout/pull/230 https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523 https://github.com/aio-libs/async-timeout/pull/237 -- components: asyncio messages: 401045 nosy: asvetlov, dreamsorcerer, yselivanov priority: normal severity: normal status: open title: asyncio.CancelledError should contain more information on cancellations type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45098> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42130] AsyncIO's wait_for can hide cancellation in a rare race condition
Change by Sam Bull : -- nosy: +dreamsorcerer nosy_count: 8.0 -> 9.0 pull_requests: +26587 pull_request: https://github.com/python/cpython/pull/28149 ___ Python tracker <https://bugs.python.org/issue42130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
Change by Sam Bull : -- pull_requests: +26076 pull_request: https://github.com/python/cpython/pull/27569 ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
Sam Bull added the comment: There is another issue with asyncio.sleep() too, if the passed argument is 0. This also tripped up the tests in aiohttp (though I've also used an explicit 0 in production code to yield back to the loop). -- ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44815] asyncio.gather no DeprecationWarning if task are passed
Change by Sam Bull : -- keywords: +patch pull_requests: +26075 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27568 ___ Python tracker <https://bugs.python.org/issue44815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
