[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

We believe that we have found a simple way to make it possible to subclass exception groups, with fully functioning split() and subgroup(). See this section in the PEP: https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups It was also added to the reference implementation. This

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi, Le 05/03/2021 à 14:46, Irit Katriel via Python-Dev a écrit : > > > Whether you have "as" or not, the value of sys.exc_info() (which is what > would be attached as the context to anything you raise in the except > block) is the same. So these are not two different cases -- the only >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Mar 4, 2021 at 11:15 PM Glenn Linderman wrote: > I like explicit, and avoiding magic. > > And this gives a compatibility story for outer loops that except: > Exception, and even for others cases that are not recoded for > ExceptionGroup handling. > It could help during the

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Mar 4, 2021 at 8:48 PM Sven R. Kunze wrote: > Hi Irit, > > makes sense. So, in case of a *mixed-type ExceptionGroup,* SystemExit > wins and forces the program to exit. > > > Could you add your reasoning to the PEP? > Good idea, I'll add "ExceptionGroup(BaseException)" as a rejected idea

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Whether you have "as" or not, the value of sys.exc_info() (which is what would be attached as the context to anything you raise in the except block) is the same. So these are not two different cases -- the only difference is whether or not you have a local variable set to sys.exc_info(). On Thu,

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 3/4/2021 1:41 AM, Irit Katriel wrote: On Thu, Mar 4, 2021 at 1:38 AM Glenn Linderman > wrote: On 3/3/2021 2:49 PM, Irit Katriel via Python-Dev wrote: That's an interesting idea. Do you mean that one exception gets handled and the rest of the

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Irit, makes sense. So, in case of a *mixed-type ExceptionGroup,* SystemExit wins and forces the program to exit. Could you add your reasoning to the PEP? This would help future readers and illustrates the chain of thoughts. It might be obvious to you but from the outside it is really a

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Le 03/03/2021 à 23:49, Irit Katriel via Python-Dev a écrit : > > On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing > wrote: > > [...] > In other words, the only difference between except and > except* would be that multiple except* clauses can be run, >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Mar 4, 2021 at 1:38 AM Glenn Linderman wrote: > On 3/3/2021 2:49 PM, Irit Katriel via Python-Dev wrote: > > That's an interesting idea. > > Do you mean that one exception gets handled and the rest of the group is > reraised? Or discarded? > > The value of sys.exc_info() (and the e in

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 3/3/2021 2:49 PM, Irit Katriel via Python-Dev wrote: On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing mailto:greg.ew...@canterbury.ac.nz>> wrote: On 4/03/21 5:37 am, Paul Moore wrote: > frameworks and libraries typically have to interact with other users' > code, and there the

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Mar 3, 2021 at 10:39 PM Greg Ewing wrote: > On 4/03/21 5:37 am, Paul Moore wrote: > > frameworks and libraries typically have to interact with other users' > > code, and there the contract has changed from "do what you like in > > your code and I'll cope" to "do what you like in your

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 4/03/21 5:37 am, Paul Moore wrote: frameworks and libraries typically have to interact with other users' code, and there the contract has changed from "do what you like in your code and I'll cope" to "do what you like in your code as long as you don't let an exception group escape, and I'll

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Mar 3, 2021 at 11:26 AM Irit Katriel via Python-Dev < python-dev@python.org> wrote: > > > On Wed, Mar 3, 2021 at 6:57 PM Paul Moore wrote: > >> Sorry, I keep thinking I've finished and you keep making interesting >> points :-) >> >> On Wed, 3 Mar 2021 at 17:01, Irit Katriel >> wrote: >>

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Sven, This is all about the popularity of "except Exception". Look at the hierarchy of builtin exceptions: https://docs.python.org/3/library/exceptions.html#exception-hierarchy Most exceptions are subclasses of Exception. There are a few which are not, because they typically mean "this

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hey Irit, find my 3 answers below: On 03.03.21 13:17, Irit Katriel wrote: Hi Sven, I like your formatting suggestion, thanks. I will do something like that. You're welcome. I'm not sure I understand your question. ExceptionGroup is a subclass of Exception (which is a subclass of

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Mar 3, 2021 at 6:57 PM Paul Moore wrote: > Sorry, I keep thinking I've finished and you keep making interesting > points :-) > > On Wed, 3 Mar 2021 at 17:01, Irit Katriel > wrote: > > > Raising an ExceptionGroup is an API change. If you call APIs that say > they will raise

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Sorry, I keep thinking I've finished and you keep making interesting points :-) On Wed, 3 Mar 2021 at 17:01, Irit Katriel wrote: > Raising an ExceptionGroup is an API change. If you call APIs that say they > will raise ExceptionGroups you need to update your code accordingly. If a > library

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Mar 3, 2021 at 4:37 PM Paul Moore wrote: > > Similar to the argument for "except Exception". Applications that trap > KeyboardInterrupt so that they can exit cleanly without an ugly > traceback will no longer trap *all* keyboard interrupts, as they could > miss grouped ones. > See

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Just to add +1 for Paul's concerns. Even though ExceptionGroups "are not supposed" to not leak into caller code, don't mean they "won't". Making "except Exception" catch them would make this part a non issue, and the feature looks great otherwise. On Wed, 3 Mar 2021 at 13:44, Paul Moore wrote:

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, 3 Mar 2021 at 14:59, Irit Katriel wrote: >> 2. Given the above, why even have a means of grouping BaseExceptions >> at all? Why not just have ExceptionGroup that can only catch instances >> of Exception? > > Because the IGotInterrupted alternative involves wrapping a BaseException by >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Paul, On Wed, Mar 3, 2021 at 2:20 PM Paul Moore wrote: > > 1. Having now read the PEP, I don't actually see a use case for > grouping BaseExceptions. Why would anyone catch KeyboardInterrupt or > SystemExit and wrap them in a BaseExceptionGroup anyway? It seems to > me that the right thing

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, 3 Mar 2021 at 12:37, Irit Katriel wrote: > This is covered the PEP, but TL;DR: > If we could make "except KeyboardInterrupt" catch > BaseExceptionGroup([KeyboardInterrupt]) in a reasonably backwards compatible > way then we wouldn't need except*. [...] > As you noted, no library is

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Paul, I agree that your condition (1) is essential, while condition (2) is desirable. (I explained in the email you replied to why I think 2 is less critical than 1). The current state of the PEP is that ExceptionGroup does not wrap BaseExceptions and is caught by "except Exception", while

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Sven, I like your formatting suggestion, thanks. I will do something like that. I'm not sure I understand your question. ExceptionGroup is a subclass of Exception (which is a subclass of BaseException). So ExceptionGroup is caught by "except Exception" or "except BaseException".

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Tue, 2 Mar 2021 at 21:46, Irit Katriel via Python-Dev wrote: > As an aside - I found it interesting that the option to wrap BaseException > instances by an Exception, which came up a couple of times in this thread, > didn't generate any anxiety. Probably because it wasn't clear that was

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Tue, Mar 2, 2021 at 1:53 PM Irit Katriel via Python-Dev < python-dev@python.org> wrote: > [...] > I can't imagine people building deep trees of exceptions in practice (at > least not on purpose). But some nesting may show up naturally, and we need > to support it because otherwise it can get

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Barry, On Mon, Mar 1, 2021 at 6:12 PM Barry Scott wrote: > > Have you considered alternative syntax to the "except*"? > I feel that expect* is too easy to confuse with plain except. > We briefly considered things like "except Group[ValueError, TypeError]". Do you (or anyone else) have any

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hey Irit, cool proposal. I just have two questions regarding "except Exception" or "except BaseException" as it is used e.g. by concurrent.futures.process (def _process_worker) from the stdlib. Almost similarly, I maintain a library using this pattern to wrap/unwrap exceptions from remote

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

> On 23 Feb 2021, at 00:24, Irit Katriel via Python-Dev > wrote: > > > Hi all, > > We would like to request feedback on PEP 654 -- Exception Groups and except*. > > https://www.python.org/dev/peps/pep-0654/ > > > It proposes language extensions

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Sven, On Mon, Mar 1, 2021 at 8:59 PM Sven R. Kunze wrote: > Hey Irit, > > cool proposal. > Thank you. > I just have two questions regarding "except Exception" or "except > BaseException" as it is used e.g. by concurrent.futures.process (def > _process_worker) from the stdlib. > > Almost

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Just to be on the safe side here, I would want to asked a little bit further. On 02.03.21 12:22, Irit Katriel wrote: 1) What is the right "except pattern" when ExceptionGroup is introduced for the use cases described above (remote or concurrent python processes)? If you want to

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 28Feb2021 20:05, Guido van Rossum wrote: >I'm trying to shorten this again... > >On Sun, Feb 28, 2021 at 5:54 PM Cameron Simpson wrote: >> Let's turn this on its head: >> - what specific harm comes from giving EGs container truthiness for >> size >> testing? > >For something that's not a

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

I'm trying to shorten this again... On Sun, Feb 28, 2021 at 5:54 PM Cameron Simpson wrote: > > Let's turn this on its head: > > - what specific harm comes from giving EGs container truthiness for size > testing? > For something that's not a pure container, this is an anti-pattern. No other

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 28Feb2021 23:56, Irit Katriel wrote: >If you go long, I go longer :) :-) >On Sun, Feb 28, 2021 at 10:51 PM Cameron Simpson wrote: >> On 28Feb2021 10:40, Irit Katriel wrote: >> >split() and subgroup() take care to preserve the correct metadata on >> >all >> >the internal nodes, and if you

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Cameron, If you go long, I go longer :) On Sun, Feb 28, 2021 at 10:51 PM Cameron Simpson wrote: > On 28Feb2021 10:40, Irit Katriel wrote: > >split() and subgroup() take care to preserve the correct metadata on > >all > >the internal nodes, and if you just use them you only make safe >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sat, 27 Feb 2021 at 00:35, Guido van Rossum wrote: > On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla > wrote: >> >> Excuse me if I post here. Maybe is a stupid question: why, instead of >> introducing except*, Python can't extend the functionality of except, >> so it can do what except* would

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 27Feb2021 00:54, Irit Katriel wrote: >On Sat, Feb 27, 2021 at 12:47 AM Jim J. Jewett wrote: >> > Is this not allowed? >> >> >try: >> >try: >> >obj.func()# function that raises ExceptionGroups >> >except AttributeError: >> >logger.info("obj doesn't have a func") >>

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

This message is longer than I had anticipated. To aid comprehension, I'm: - accepting that .split and .subgroup help my "handle some excpetions but not others" situation, barely - arguing for ExceptionGroups acting like other containers: truthy if nonempty, falsey if empty; iterable;

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

You can pass an arbitrary function to eg.split() and eg.subgroup(), and that function can have a side effect. Suppose you want to log and ignore OSError with errno==ENOENT but re-raise the rest, you can do this: ``` def log_and_ignore(err): if err.errno == ENOENT: log(err)

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Looking at the following PEP example, I'm still not sure what he should do to handle some but not all OSError instances: ...raise ExceptionGroup( ... "eg", ... [ ... ValueError(1), ... TypeError(2), ... OSError(3), ...

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sun, Feb 28, 2021 at 6:17 PM Guido van Rossum wrote: > On Sun, Feb 28, 2021 at 2:40 AM Irit Katriel > wrote: > >> >> In earlier versions of the PEP ExceptionGroup was not immutable and split >> actually removed matching exceptions from it. >> It was also iterable so you could get a flat list

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sun, Feb 28, 2021 at 2:40 AM Irit Katriel wrote: > > In earlier versions of the PEP ExceptionGroup was not immutable and split > actually removed matching exceptions from it. > It was also iterable so you could get a flat list of all the contained > leaf exceptions. Then we changed it. > >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

In earlier versions of the PEP ExceptionGroup was not immutable and split actually removed matching exceptions from it. It was also iterable so you could get a flat list of all the contained leaf exceptions. Then we changed it. ExceptionGroup is a tree of exceptions, and the internal nodes of the

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

We really don’t want users pushing non-exceptions into the list, nor do we want e.g. KeyboardInterrupt to be added to a (non-Base-) ExceptionGroup. There’s a pattern for what you propose using the split() method and a lambda, or you can keep the exceptions in a list and re-wrap them at the end.

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 26Feb2021 02:44, Irit Katriel wrote: >On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum wrote: >> OT: Is ExceptionGroup *really* immutable in the current >> implementation? As >> long as the 'errors' field is a list, I think one could mutate the list >> directly. > >It's not, but we were

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 2/27/21 2:37 AM, Paul Moore wrote: On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: Whenever I've used except Exception or stronger, it was a sanitary barrier around code that might well do unpredictable or even stupid things. Adding a new kind of exception that I hadn't predicted --

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: > Whenever I've used except Exception or stronger, it was a sanitary > barrier around code that might well do unpredictable or even stupid > things. Adding a new kind of exception that I hadn't predicted -- > including ExceptionGroup -- would

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sat, Feb 27, 2021 at 1:09 PM Jim J. Jewett wrote: > > In fact, if you're happy with RuntimeError here, making > > ExceptionGroup inherit from Exception (instead of > > BaseException) would do just as well -- after all RuntimeError > > is pretty arbitrary > > Agreed, and I think it should

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sat, Feb 27, 2021 at 2:39 AM Paul Moore wrote: > On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: > > > > Whenever I've used except Exception or stronger, it was a sanitary > barrier around code that might well do unpredictable or even stupid > things. Adding a new kind of exception that

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

> In fact, if you're happy with RuntimeError here, making > ExceptionGroup inherit from Exception (instead of > BaseException) would do just as well -- after all RuntimeError > is pretty arbitrary Agreed, and I think it should inherit from Exception. > (in fact, it's wrong, because the problem

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, 26 Feb 2021 at 23:36, Jim J. Jewett wrote: > > Whenever I've used except Exception or stronger, it was a sanitary barrier > around code that might well do unpredictable or even stupid things. Adding a > new kind of exception that I hadn't predicted -- including ExceptionGroup -- >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

> Why would you want a different flavor of ExceptionGroup? The easiest example you took care of by saving the exceptions in a list instead of a set. Next would be the ExceptionGroup vs BaseExceptionGroup that I *don't* like, but someone might. There are also libraries that promise to raise

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

ValueError("Partner: 3 File: 127 record: 93 is missing field: currency") tells the production support people who to contact and what to say. I'm not sure what additional context would be helpful, let alone how it might have been available "at the time", but lost now that the ValueAttribute

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sat, Feb 27, 2021 at 12:35 AM Greg Ewing wrote: > While I don't particularly mind if we get ExceptionGroup, giving > it special magical semantics, and especially new syntax, seems like > bringing a massively overpowered weapon to bear on something that > will only be used rarely. > > Handling

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, Feb 26, 2021 at 11:43 PM Guido van Rossum wrote: > On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla > wrote: > >> Excuse me if I post here. Maybe is a stupid question: why, instead of >> introducing except*, Python can't extend the functionality of except, >> so it can do what except* would

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Sat, Feb 27, 2021 at 12:47 AM Jim J. Jewett wrote: > > > Is this not allowed? > > >try: > >try: > >obj.func()# function that raises ExceptionGroups > >except AttributeError: > >logger.info("obj doesn't have a func") > >except *(AttributeError, SyntaxError): > >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

> Thank you for turning to what happens with 'except ValueError' when an > ExceptionGroup[ValueError] is raised, this is important. > I'm not sure it's safe to assume that it is necessarily a > programming >error, and that the interpreter can essentially break the program in this > case. I'm

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

While I don't particularly mind if we get ExceptionGroup, giving it special magical semantics, and especially new syntax, seems like bringing a massively overpowered weapon to bear on something that will only be used rarely. Handling multiple exceptions from an ExceptionGroup could be done using

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

You still need except* for the (unusual?) case where the ExceptionGroup contains multiple individual Exceptions, and you want them all to be processed. (This possibility is the justification for the PEP, but the difficulty of associating an exception with the specific task that raised it

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

FWIW, the only situation I can think of where you would care that the enclosed exception instances are BaseException but not regular Exception is interactive debugging, and even then there are enough other ways to kill the whole process that I think most people would use one of them instead of

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla wrote: > Excuse me if I post here. Maybe is a stupid question: why, instead of > introducing except*, Python can't extend the functionality of except, > so it can do what except* would do? > Good question. Here's an example: ``` try: . . . except

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

> We keep the ability to wrap any exception, while we lose the "fail-fast if > you forget to handle an ExceptionGroup" feature, which was intended as a > kindness towards those who abuse "except Exception". How is this a kindness? Whenever I've used except Exception or stronger, it was a

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Feb 25, 2021 at 9:40 PM Nathaniel Smith wrote: > [...] > Yury/I/others did discuss the idea of a > BaseExceptionGroup/ExceptionGroup split a lot, and I think the general > feeling is that it could potentially work, but feels like a > complicated and awkward hack, so no-one was super

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Excuse me if I post here. Maybe is a stupid question: why, instead of introducing except*, Python can't extend the functionality of except, so it can do what except* would do? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, Feb 26, 2021 at 2:42 PM Nathaniel Smith wrote: > On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel > wrote: > > I'm not sure it's safe to assume that it is necessarily a programming > error, and that the interpreter can essentially break the program in this > case. > > Is this not allowed? >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

A side benefit is that if an Exception somehow propagates up where only ExceptionGroup is defined, except *() could just work anyway, though it might take a little magic to make sure they act the same. Like Guido said, I don't think it can be retrofitted into existing *-less APIs, and it'll either

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel wrote: > I'm not sure it's safe to assume that it is necessarily a programming error, > and that the interpreter can essentially break the program in this case. > Is this not allowed? > > try: > try: > obj.func()# function that raises

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

FTR: nobody on this long thread so far has suggested that there are no valid use cases for `except Exception`. Thank you for turning to what happens with 'except ValueError' when an ExceptionGroup[ValueError] is raised, this is important. I'm not sure it's safe to assume that it is necessarily a

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Feb 25, 2021 at 10:23 PM Glenn Linderman wrote: > So then why do you need except* at all? Only to catch unwrapped > ExceptionGroup before it gets wrapped? > > So why not write except ExceptionGroup, and let it catch unwrapped > ExceptionGroup? > > That "CUTE BIT" could be done only

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On 2/25/2021 9:40 PM, Nathaniel Smith wrote: On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum wrote: So is "fail-fast if you forget to handle an ExceptionGroup" really a feature? (Do we call this out in the PEP?) We may believe that "except Exception" is an abuse, but it is too common to

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum wrote: > > So is "fail-fast if you forget to handle an ExceptionGroup" really a feature? > (Do we call this out in the PEP?) > > We may believe that "except Exception" is an abuse, but it is too common to > dismiss out of hand. I think if some

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum wrote: > Then we should get some more opinions on this. I think it's the best idea > so far for kindness towards code using `except Exception:`. > I agree that it's the best idea so far. If someone says 'except Exception' they better mean it

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Great. Let’s wait for others to catch up with the discussion then. On Thu, Feb 25, 2021 at 18:44 Irit Katriel wrote: > > > On Fri, Feb 26, 2021 at 2:00 AM Guido van Rossum wrote: > >> Then we should get some more opinions on this. I think it's the best idea >> so far for kindness towards code

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Feb 25, 2021 at 9:06 PM Guido van Rossum wrote: > > Hm, a different idea: maybe it's simple enough that we can just add an > example showing how to do this? Then people can tailor that e.g. to use > various traversal orders. (We could just link to the code in traceback.py, > but it

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Then we should get some more opinions on this. I think it's the best idea so far for kindness towards code using `except Exception:`. I even think that the names I came up with are reasonable. The pseudo-code needs work: when instantiating ExceptionGroup, all errors should inherit from Exception,

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

We don't call it out but we talked about this at the sprint. I think the reason we didn't come up with this solution then is that at the time ExceptionGroups in our plans were not immutable, so this would not have been possible (you don't know at construction time what it is going to contain).

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

So is "fail-fast if you forget to handle an ExceptionGroup" really a feature? (Do we call this out in the PEP?) We may believe that "except Exception" is an abuse, but it is too common to dismiss out of hand. I think if some app has e.g. a main loop where they repeatedly do something that may

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Good question. The main use case I see for iterating over individual exceptions is logging frameworks that want to format their own exception tracebacks for whatever reason. I know that the traceback.py module has extensive utilities for exactly that, but I betcha there are plenty of people who

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Feb 25, 2021 at 5:19 AM Guido van Rossum wrote: > [Subthread: handling individual errors] > > > Rather than iterator, I think we should add a visitor that calls a > function for each leaf exception, > > I agree that we shouldn't add an `__iter__` method. But what if we added a > separate

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Thu, Feb 25, 2021 at 5:59 AM Guido van Rossum wrote: > > Here's a potentially alternative plan, which is also complex, but doesn't > require asyncio or other use cases to define special classes. Let's define > two exceptions, BaseExceptionGroup which wraps BaseException instances, and >

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Feb 24, 2021 at 1:38 AM Irit Katriel wrote: > > > On Wed, Feb 24, 2021 at 4:39 AM Guido van Rossum wrote: > >> >> OTOH we might reconsider deriving ExceptionGroup from BaseException -- >> maybe it's better to inherit from Exception? I don't think the PEP >> currently has a clear reason

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Feb 24, 2021 at 7:09 PM Emily Bowman wrote: > After reading through the PEP and skimming the code (but I didn't build > it), something I didn't see: What happens to a currently conforming except > check? > > try: > async with trio.open_nursery() as nursery: > # Make two

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Feb 24, 2021 at 5:58 PM Jim J. Jewett wrote: > If it (compatible __new__ and __init__) needs to be checked at definition > time, just try create an instance passing the same arguments you would pass > to the base class. If the creation it doesn't raise an exception, that is > good

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Feb 24, 2021 at 5:51 PM Jim J. Jewett wrote: > Are you saying that > > except *ValueError as e: > > will catch > > ValueError > and > ExceptionGroup(ValueError) > but miss > ExceptionGroup(ExceptionGroup(ValueError)) > ? > No, it will catch it regardless of how many

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Subthread: handling individual errors] > Rather than iterator, I think we should add a visitor that calls a function for each leaf exception, I agree that we shouldn't add an `__iter__` method. But what if we added a separate method that returns an iterator? Then you could write ``` for e in

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

After reading through the PEP and skimming the code (but I didn't build it), something I didn't see: What happens to a currently conforming except check? try: async with trio.open_nursery() as nursery: # Make two concurrent calls to child() nursery.start_soon(child)

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Ideally, (at least) trivial subclasses could be declared, and the class itself would serve as the marker. I would prefer regular subclasses, so that they could offer methods as well. Alternatively, at least copy the instance __dict__ to the new ExceptionGroup instance. By compatible __init__

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

If it (compatible __new__ and __init__) needs to be checked at definition time, just try create an instance passing the same arguments you would pass to the base class. If the creation it doesn't raise an exception, that is good enough. This isn't about theoretical type safety against malice;

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Are you saying that except *ValueError as e: will catch ValueError and ExceptionGroup(ValueError) but miss ExceptionGroup(ExceptionGroup(ValueError)) ? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

By the time a KeyboardInterrupt or SystemExit is being grouped into an ExceptionGroup, it already isn't being treated as an immediate interruption ... it has (presumably) already killed its own execution path, but it should not kill the program as a whole. Whether ExceptionGroup inherits from

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Ethan, See Irit's response to my about why ExceptionGroup doesn't subclass Exception -- I think this is still a little bit of an open issue. Another response (which I also read somewhere in one of Irit's messages) is that a library API shouldn't go from raising subclasses of Exception only to

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Jim, Let me echo Irit's response here -- what's your use case for subclassing ExceptionGroup? Requiring that subclasses have a compatible __init__ or __new__ sounds like a bug magnet, since this can't be checked when the subclass is being defined, and it goes against conventional rules for

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Hi Jim, On Wed, Feb 24, 2021 at 2:16 PM Jim J. Jewett wrote: > Petr: What about except *(TypeError, ExceptionGroup):? > > Irit: Good question. We should block that as well. > > But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility > seems to explicitly recommend the very

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Feb 24, 2021 at 4:39 AM Guido van Rossum wrote: > > OTOH we might reconsider deriving ExceptionGroup from BaseException -- > maybe it's better to inherit from Exception? I don't think the PEP > currently has a clear reason why it must derive from BaseException. I > believe it has to do

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Wed, Feb 24, 2021 at 4:55 AM Guido van Rossum wrote: However there may be an omission in the PEP -- what if we want to do > something special for each suberror? If we just iterate over `eg.errors` we > would have to do something recursive for exceptions wrapped inside multiple > nested

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Please include an example for: except *ExceptionGroup: pass I *think* it swallows all exceptions, instead of re-raising. I *think* it also catches (and then swallows) bare exception that were not initially part of an ExceptionGroup. I *think* it catches anything that gets raised, not just

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

The "no subclasses" seems pretty severe, particularly if you can't even use marker attributes because it isn't clear when a different instance of container ExceptionGroup will be substituted. The justification for this restriction was that .split() had to be be able to instantiate ... wouldn't

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

Petr: What about except *(TypeError, ExceptionGroup):? Irit: Good question. We should block that as well. But https://www.python.org/dev/peps/pep-0654/#backwards-compatibility seems to explicitly recommend the very similar: except (Exception, ExceptionGroup):

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Tue, Feb 23, 2021 at 11:00 PM Irit Katriel wrote: > > Hi Steve, > > Thank you for trying out the implementation. Please do let me know about > bugs you find. > > Thanks you for your response! It seems I had missed the (now) obvious naked exception wrapping logic. Apologies for adding noise

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

On Tue, Feb 23, 2021 at 8:00 AM Ivan Pozdeev via Python-Dev < python-dev@python.org> wrote: > >- In >https://www.python.org/dev/peps/pep-0654/#programming-without-except, >the natural way isn't shown: > > try: > > except (MultiError, ValueError) as e: > def _handle(e): >

  1   2   >