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

[Paul Moore]

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 ever being proposed... (or
at least the implication wasn't obvious - presumably this is somehow
related to BaseExceptions being accumulated in ExceptionGroups?) :-(

I would consider it essential that if someone hits Ctrl-C and that
generates a KeyboardInterrupt, then:

1. That KeyboardInterrupt will *not* get caught by exception handlers
only interested in Exception instances
2. That KeyboardInterrupt *will* get caught by any handler that does
an explicit `except KeyboardInterrupt` or an `except BaseException`.

To me, that's pretty much essential to correct Ctrl-C handling in any
app (never ignore a user's Ctrl-C and always exit cleanly if one is
raised).

That might mean that BaseException instances shouldn't be "groupable",
but I don't want to comment on that until I've properly read the PEP
(I've skimmed it now, but only superficially). At a minimum, I'd
consider it a bug for library code to manually wrap a
KeyboardInterrupt in an exception group (just like code that catches
KeyboardInterrupt and re-raises it as a ValueError would be today).

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S5SPIFHGWASEGKBITWPDDRXOU33NLG46/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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". BaseExceptionGroup
is a subclass only of BaseException so it is caught by "except
BaseException" but not "except Exception". And ExceptionGroup is allowed to
wrap only Exceptions while BaseException can wrap Exceptions and and
BaseExceptions. Makes sense?

Irit


On Tue, Mar 2, 2021 at 7:25 PM Sven R. Kunze  wrote:

> 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 catch the whole ExceptionGroup and format its traceback,
> then you can just do "except ExceptionGroup as eg" and then
> traceback.print_exception(eg).
>
> The except* syntax is for when you want to handle only certain types of
> exceptions from the group, selectively.
>
> Just to make sure, I understand this completely.
>
>
> In order to make it more tangible here is an example from the stdlib:
>
>
> https://github.com/python/cpython/blob/bf2e7e55d7306b1e2fce7dce767e8df5ff42cf1c/Lib/concurrent/futures/process.py#L215
>
> As you can see, BaseException is caught multiple times as the only
> except-clause. _sendback_result(...) then used to transfer the
> return_val/exception back to parent process.
>
>
> How is the supposed way of handling a raised ExceptionGroup?
>
>
> a) will the existing code simply work as it?
> b) if not what are the changes to this lib specifically as a blueprint
> example for others
>
>
> Reading from the other subthread for this PEP, I am not 100% sure now that
> "except BaseException" will suffice if ExceptionGroup inherits from
> Exception instead of BaseException because it seems that ExceptionGroup
> somehow is handled specially. So, why I try to approach this very issue
> with existing code. Once that is clear, it should be easy for everybody to
> apply the same pattern to their code. Here is the copy from github:
>
>
> try:
> r = call_item.fn(*call_item.args, **call_item.kwargs)
> except BaseException as e:
> exc = _ExceptionWithTraceback(e, e.__traceback__)
> _sendback_result(result_queue, call_item.work_id, exception=exc)
> else:
> _sendback_result(result_queue, call_item.work_id, result=r)
> del r
>
>
> Maybe even _sendback_result could benefit from using ExceptionGroup
> itself. You can see there another "except BaseException" in case of an
> error. But that's maybe a different topic.
>
>
>
>> 2) What is the recommended approach of printing the traceback potentially
>> incorporating multiple tracebacks - I couldn't find it in the PEP and
>> tracebacks are a really neat tool for error hunting.
>>
>
> Part of the proposal of the PEP is that we teach the builtin traceback
> formatting code to display ExceptionGroups with all that information.
>
>
> As long as there's the possibility to receive the usual (two-line)
> entry-based list, I guess that is enough for every one to work with it
> (e.g. hiding unnecessary tb entries).
>
>
> The reference implementation has this, and the examples in the PEP were
> produced with it. Some of the examples (the early ones) show exceptions
> that were never raised so there is no traceback. But if you scroll down to
> the later examples, you see the output for exceptions with tracebacks,
> cause, context etc.
>
>
> Ah I see them now. Thank you. :-)
>
>
> We didn't put too much effort into making the traceback output pretty, so
> at the moment it's a draft. If there is an ascii artist out there who has
> suggestions on improving this, that would be great.
>
>
> Well, yes. It's not really pretty. I would recommend a tree-based solution
> such as the following:
>
>
> Traceback (most recent call last):
>   File "", line 3, in 
> ExceptionGroup
> |
> +---+   Traceback (most recent call last):
> |   | File "", line 3, in 
> |   |   ExceptionGroup: eg
> |   |   |
> |   |   +---+ ValueError: a
> |   |
> |   |   During handling of the above exception, another exception occurred:
> |   |
> |   |   Traceback (most recent call last):
> |   | File "", line 5, in 
> |   |   KeyError: 'x'
> |
> |
> +---+   Traceback (most recent call last):
> |   | File "", line 3, in 
> |   |   ExceptionGroup: eg
> |   |   |
> |   |   +---+ TypeError: b
>
>
> I used a similar pattern for the remote-execution lib and received good
> user feedback (even requesting color encoding for each layer of the tree
> (not the text), so people know what belongs together). Besides colors, I
> used https://en.wikipedia.org/wiki/Box-drawing_character but I guess
> pipes, dashes and pluses could suffice for CPython.
>
>
> One other remark from my side here: in the exa

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

[Irit Katriel via Python-Dev]

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
BaseExceptionGroup wraps BaseException and is only caught by "except
BaseException" but not "except Exception".

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*.

For example, suppose that this:

try:
raise BaseExceptionGroup([KeyboardInterrupt()])
except  KeyboardInterrupt:
   email_the_boss()

worked as you suggest. Then what should this do?  Send two emails to the
boss?

try:
raise BaseExceptionGroup([KeyboardInterrupt(), KeyboardInterrupt() ])
except  KeyboardInterrupt:
   email_the_boss()


As you noted, no library is under any obligation to wrap KeyboardInterrupts
into the exception groups it raises. You may decide it's a bad idea and not
do it.  What we are discussing here is what the language should make
possible. We agree that wrapping a BaseException by an Exception is
something we should definitely block. When it's wrapping a BaseException by
another, new BaseException type, in my view that's ok. You may have a bug
where you don't catch an exception you want to catch, because you are using
a new API incorrectly. But you won't have bugs where you swallow an
exception that you didn't swallow before.

Irit


On Wed, Mar 3, 2021 at 8:30 AM Paul Moore  wrote:

> 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 ever being proposed... (or
> at least the implication wasn't obvious - presumably this is somehow
> related to BaseExceptions being accumulated in ExceptionGroups?) :-(
>
> I would consider it essential that if someone hits Ctrl-C and that
> generates a KeyboardInterrupt, then:
>
> 1. That KeyboardInterrupt will *not* get caught by exception handlers
> only interested in Exception instances
> 2. That KeyboardInterrupt *will* get caught by any handler that does
> an explicit `except KeyboardInterrupt` or an `except BaseException`.
>
> To me, that's pretty much essential to correct Ctrl-C handling in any
> app (never ignore a user's Ctrl-C and always exit cleanly if one is
> raised).
>
> That might mean that BaseException instances shouldn't be "groupable",
> but I don't want to comment on that until I've properly read the PEP
> (I've skimmed it now, but only superficially). At a minimum, I'd
> consider it a bug for library code to manually wrap a
> KeyboardInterrupt in an exception group (just like code that catches
> KeyboardInterrupt and re-raises it as a ValueError would be today).
>
> Paul
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5M6YSXXZWGUHE5VOFLJWKRSUY4TIXLTH/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 under any obligation to wrap KeyboardInterrupts 
> into the exception groups it raises. You may decide it's a bad idea and not 
> do it.  What we are discussing here is what the language should make 
> possible. We agree that wrapping a BaseException by an Exception is something 
> we should definitely block. When it's wrapping a BaseException by another, 
> new BaseException type, in my view that's ok. You may have a bug where you 
> don't catch an exception you want to catch, because you are using a new API 
> incorrectly. But you won't have bugs where you swallow an exception that you 
> didn't swallow before.

Thanks for the explanation. I understand your point here, and I see
what you're saying. But I have a couple of questions still:

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 to do, even in async or parallel code, is to
just propogate the KeyboardInterrupt/SystemExit up to the main
program. Losing a ValueError that happened at the exact same time as
the user pressed Ctrl-C seems like it's not going to be a problem in
practice...
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?

If there really *was* a low-level case where some code absolutely had
to (temporarily) group KeyboardInterrupt, for example, it could be
temporarily wrapped:

class IGotInterrupted(Exception):
def __init__(self, exc):
self.exc = exc

def might_be_interrupted():
try:
critical_stuff()
except KeyboardInterrupt as exc:
raise IGotInterrupted(exc)

def funky_parallel_stuff():
try:
do_in_parallel(might_be_interrupted)
except *IGotInterrupted as e:
# Please excuse the fact that I don't know the
# correct way to re-raise here. Might need raise from.
raise e.exc
# Do we also need to consider an *ungrouped* IGotInterrupted?
# That's for the library to decide, and is why not letting it
escape is a good thing...

That would be appropriate for really low-level code, and it would be a
fairly obvious anti-pattern for an exception class like
IGotInterrupted to "escape" so that user code would ever see it.

I guess the argument for grouping BaseExceptions is "why make it
necessary to do complicated wrapping like this?" To which my answer is
"because it should almost never be something you do, and so why add
support for it when it can be done *without* needing explicit support
in the PEP?" And by not having stdlib support for wrapping
BaseExceptions, we're signalling that we don't think people should be
doing it casually...

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5LVHBCIWOLYVUYAMFYIZAPEDV7JUVBYS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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 to do, even in async or parallel code, is to
> just propogate the KeyboardInterrupt/SystemExit up to the main
> program. Losing a ValueError that happened at the exact same time as
> the user pressed Ctrl-C seems like it's not going to be a problem in
> practice...
>


It is possible that your program wants to do something other than just
terminate when it gets a KeyboardInterrupt. Otherwise why does the
interpreter bother propagating the KeyboardInterrupt rather than just
terminate the program there and then?

And the ValueError you lost may be some other error type that involves
cleanup.

If you do this:

try:
async.gather(...)  # raises BaseExceptionGroup( DoCleanup(),
KeyboardInterrupt())
except * DoCleanup:
do_cleanup() # log stuff, send notifications, close sockets, whatever

That will do the cleanup in addition to propagating a
BaseExceptionGroup(KeyboardInterrupt())

Also, KeyboardInterrupt/SystemExit are not the only BaseExceptions.



> 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 an Exception, which is not something we should push people into doing
(it's not that different from allowing ExceptionGroup to wrap
BaseExceptions directly).

What's the harm/complication in offering a
BaseExceptionGroup(BaseException) in addition to
ExceptionGroup(BaseExceptionGroup, Exception)?


I think the only reason you're comfortable with having to select between
the exceptions that were raised and discard some of them is because that's
where we are today. The PEP lists several standard library and other APIs
that discard errors because they need to pick one. That's what we're trying
to fix.

Irit
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7HHNSKCF4DEBAWR2PUAVQ2QXNSJMWMHS/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 
> an Exception, which is not something we should push people into doing (it's 
> not that different from allowing ExceptionGroup to wrap BaseExceptions 
> directly).

That's a fair point.

> What's the harm/complication in offering a BaseExceptionGroup(BaseException) 
> in addition to ExceptionGroup(BaseExceptionGroup, Exception)?

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.

If we accept that grouped exceptions should never escape out of a
well-defined context, then this wouldn't be such an issue. But there's
nothing in the PEP that enforces that, and there *is* code that needs
to be prepared for "any sort of result". It's the except Exception
argument again.

So code that wants to exit cleanly in the face of Ctrl-C will need to
be rewritten from:

try:
main()
except KeyboardInterrupt:
print("User interrupted the program. Exiting")
sys.exit(1)

to:

try:
try:
main()
except KeyboardInterrupt:
print("User interrupted the program. Exiting")
sys.exit(1)
except *KeyboardInterrupt:
print("User interrupted the program. Exiting")
sys.exit(1)

Did I miss an easier way of writing this code? And worse, how would I
write it so that it was portable between Python 3.9 and later versions
(which is a common requirement for library code - admittedly library
code wouldn't normally be doing this sort of top-level trap, but it
could just as easily be "catch Ctrl-C and do a bit of tidy-up and
re-raise").

> I think the only reason you're comfortable with having to select between the 
> exceptions that were raised and discard some of them is because that's where 
> we are today. The PEP lists several standard library and other APIs that 
> discard errors because they need to pick one. That's what we're trying to fix.

Maybe. But I'm not looking at it as being "comfortable" with the
current situation, but rather as "I don't use any of these new
features, why am I having to change my code to accommodate stuff I
don't use?" If I own the full stack, that's not an issue, but
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 cope"... And I have
to change *my* code to get the old contract back.

But it's a small point in the wider scheme of things, and I'm not
going to labour the point any more. Thanks for listening and taking
the time to reply.

Paul

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WSUEOGDCBBOZ7PCQGUCXKIZEZ7RK34LK/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Joao S. O. Bueno]

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:

> 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 an Exception, which is not something we should push people
> into doing (it's not that different from allowing ExceptionGroup to wrap
> BaseExceptions directly).
>
> That's a fair point.
>
> > What's the harm/complication in offering a
> BaseExceptionGroup(BaseException) in addition to
> ExceptionGroup(BaseExceptionGroup, Exception)?
>
> 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.
>
> If we accept that grouped exceptions should never escape out of a
> well-defined context, then this wouldn't be such an issue. But there's
> nothing in the PEP that enforces that, and there *is* code that needs
> to be prepared for "any sort of result". It's the except Exception
> argument again.
>
> So code that wants to exit cleanly in the face of Ctrl-C will need to
> be rewritten from:
>
> try:
> main()
> except KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
>
> to:
>
> try:
> try:
> main()
> except KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
> except *KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
>
> Did I miss an easier way of writing this code? And worse, how would I
> write it so that it was portable between Python 3.9 and later versions
> (which is a common requirement for library code - admittedly library
> code wouldn't normally be doing this sort of top-level trap, but it
> could just as easily be "catch Ctrl-C and do a bit of tidy-up and
> re-raise").
>
> > I think the only reason you're comfortable with having to select between
> the exceptions that were raised and discard some of them is because that's
> where we are today. The PEP lists several standard library and other APIs
> that discard errors because they need to pick one. That's what we're trying
> to fix.
>
> Maybe. But I'm not looking at it as being "comfortable" with the
> current situation, but rather as "I don't use any of these new
> features, why am I having to change my code to accommodate stuff I
> don't use?" If I own the full stack, that's not an issue, but
> 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 cope"... And I have
> to change *my* code to get the old contract back.
>
> But it's a small point in the wider scheme of things, and I'm not
> going to labour the point any more. Thanks for listening and taking
> the time to reply.
>
> Paul
>
> Paul
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/WSUEOGDCBBOZ7PCQGUCXKIZEZ7RK34LK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CYV3RDTUZM2LBF6NLCHA6PTJMWG4CKF6/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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 below.


>
> If we accept that grouped exceptions should never escape out of a
> well-defined context, then this wouldn't be such an issue. But there's
> nothing in the PEP that enforces that, and there *is* code that needs
> to be prepared for "any sort of result". It's the except Exception
> argument again.
>
> So code that wants to exit cleanly in the face of Ctrl-C will need to
> be rewritten from:
>
> try:
> main()
> except KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
>
> to:
>
> try:
> try:
> main()
> except KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
> except *KeyboardInterrupt:
> print("User interrupted the program. Exiting")
> sys.exit(1)
>

It suffices to do

try:
main()
  except *KeyboardInterrupt:
print("User interrupted the program. Exiting")
sys.exit(1)

because "except *T" catches Ts as well.



>
> Did I miss an easier way of writing this code? And worse, how would I
> write it so that it was portable between Python 3.9 and later versions
> (which is a common requirement for library code - admittedly library
> code wouldn't normally be doing this sort of top-level trap, but it
> could just as easily be "catch Ctrl-C and do a bit of tidy-up and
> re-raise").
>

For older Pythons you would have to do something like

except KeyboardInterrupt:
   ...
except BaseExceptionGroup:  # some stub type in old versions
   # inspect the contents
   # if there's a KeyboardInterrupt do what you need to do
   # reraise the rest



>
> > I think the only reason you're comfortable with having to select between
> the exceptions that were raised and discard some of them is because that's
> where we are today. The PEP lists several standard library and other APIs
> that discard errors because they need to pick one. That's what we're trying
> to fix.
>
> Maybe. But I'm not looking at it as being "comfortable" with the
> current situation, but rather as "I don't use any of these new
> features, why am I having to change my code to accommodate stuff I
> don't use?" If I own the full stack, that's not an issue, but
> 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 cope"... And I have
> to change *my* code to get the old contract back.
>

 "except Exception"/"except BaseException" is the special case of "I don't
know what I'm calling and I want to catch everything".  And that (to
repeat, just in case) will work as you expect.

If you are actually handling exceptions selectively, then I can break you
already in 3.9 just by raising a different exception type to the one you
are catching. How is this different?

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 doesn't document that it raises ExceptionGroups and then one of
those escapes, then that library has a bug. Just like with any other
exception type.


>
> But it's a small point in the wider scheme of things, and I'm not
> going to labour the point any more. Thanks for listening and taking
> the time to reply.


It's an important one though. Thanks for asking good questions.

Irit
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SDHZAEUNHMOC2NBCFQZEDTHZ4B6QGEXO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Suggestion About Python Syntax

[Anthony Farino]

I love the Python scripting language, but there’s something that would make
it much better. Almost every other programming language uses curly braces
to enclose blocks of code and semicolons after the lines of code. That
means that:

   1.

   You can have as much white space as you want.
   2.

   You don’t need to worry about indentation, and you can indent whenever
   you want.

I hope that you consider these issues and fix them in Python 4 (if you ever
make it).

Sincerely, Anthony, age 10.


-- 
   mmm#
   ##   m mm   mm#mm  # mmmmm   m mm   m   m
  #  #  #"  ###"  #  #" "#  #"  #  "m m"
  #mm#  #   ###   #  #   #  #   #   #m#
 ## #   #"mm  #   #  "#m#"  #   #   "#
m"
   ""
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion About Python Syntax

[Joao S. O. Bueno]

That is covered.
Try typing "from __future__ import braces".

On Wed, 3 Mar 2021 at 14:47, Anthony Farino 
wrote:

> I love the Python scripting language, but there’s something that would
> make it much better. Almost every other programming language uses curly
> braces to enclose blocks of code and semicolons after the lines of code.
> That means that:
>
>1.
>
>You can have as much white space as you want.
>2.
>
>You don’t need to worry about indentation, and you can indent whenever
>you want.
>
> I hope that you consider these issues and fix them in Python 4 (if you
> ever make it).
>
> Sincerely, Anthony, age 10.
>
>
> --
>mmm#
>##   m mm   mm#mm  # mmmmm   m mm   m   m
>   #  #  #"  ###"  #  #" "#  #"  #  "m m"
>   #mm#  #   ###   #  #   #  #   #   #m#
>  ## #   #"mm  #   #  "#m#"  #   #   "#
> m"
>""
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MLNWBYE3GJ4ZUXLPQGEP4UIANP72NTSX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion About Python Syntax

[Senthil Kumaran]

Hello Anthony,

Welcome to this list. :) Python is written in C, and developers use
semicolons and branches in C. However, when Guido designed Python, he
specifically wanted white-space indented language. The idea was it
will be less intimidating to beginners and more readables.
It seems to have been a great decision and as the design is still
going strong and is unlikely to change in future.


On Wed, Mar 3, 2021 at 9:48 AM Anthony Farino  wrote:
>
> I love the Python scripting language, but there’s something that would make 
> it much better. Almost every other programming language uses curly braces to 
> enclose blocks of code and semicolons after the lines of code. That means 
> that:
>
> You can have as much white space as you want.
>
> You don’t need to worry about indentation, and you can indent whenever you 
> want.
>
> I hope that you consider these issues and fix them in Python 4 (if you ever 
> make it).
>
> Sincerely, Anthony, age 10.
>
>
>
> --
>mmm#
>##   m mm   mm#mm  # mmmmm   m mm   m   m
>   #  #  #"  ###"  #  #" "#  #"  #  "m m"
>   #mm#  #   ###   #  #   #  #   #   #m#
>  ## #   #"mm  #   #  "#m#"  #   #   "#
> m"
>""
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at 
> https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DZC4DZIASQJKZSAYV3VJP5WRZKEGMRFC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Suggestion About Python Syntax

[George Harding]

Hi Anthony,

The python-dev mailing list is used for discussion between the python core
developers. I'll forward your suggestion to the python-ideas mailing list,
where many interesting ideas for python are discussed:

https://mail.python.org/archives/list/python-id...@python.org/

Best,

George

On Wed, Mar 3, 2021 at 5:52 PM Anthony Farino 
wrote:

> I love the Python scripting language, but there’s something that would
> make it much better. Almost every other programming language uses curly
> braces to enclose blocks of code and semicolons after the lines of code.
> That means that:
>
>1.
>
>You can have as much white space as you want.
>2.
>
>You don’t need to worry about indentation, and you can indent whenever
>you want.
>
> I hope that you consider these issues and fix them in Python 4 (if you
> ever make it).
>
> Sincerely, Anthony, age 10.
>
>
> --
>mmm#
>##   m mm   mm#mm  # mmmmm   m mm   m   m
>   #  #  #"  ###"  #  #" "#  #"  #  "m m"
>   #mm#  #   ###   #  #   #  #   #   #m#
>  ## #   #"mm  #   #  "#m#"  #   #   "#
> m"
>""
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RZR2O3Y6Z6RCAXW72Y4WPWZ6HN3MYVFJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U2UBZBWBAWCFLPIG3RWQPJN7W2ISXPIE/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Paul Moore]

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 doesn't document that it raises ExceptionGroups and then one of those 
> escapes, then that library has a bug. Just like with any other exception type.

In my experience, libraries don't document what exceptions they raise
very well. You can call that a bug, but it's a fact of life, I'm
afraid. The problem here isn't so much that the library code now
raises an exception that it used not to raise, but rather that *the
user hitting Ctrl-C* can now result in a different exception surfacing
in my code than it used to. Libraries don't re-wrap KeyboardInterrupt,
as you pointed out in a previous response, so I can currently write
code that traps KeyboardInterrupt, safe in the knowledge that by doing
so I'll handle that user action properly. But with PEP 654, libraries
might well (indeed, some libraries almost certainly will) start
wrapping KeyboardInterrupt in an exception group. That's a backward
incompatible change from the perspective of my code's interaction with
the user, and I need to re-code my application to deal with it (and
worse still, writing that new code in a way that is portable between
versions is not particularly straightforward).

> For older Pythons you would have to do something like
>
> except KeyboardInterrupt:
>...
> except BaseExceptionGroup:  # some stub type in old versions
># inspect the contents
># if there's a KeyboardInterrupt do what you need to do
># reraise the rest

I'd be inclined to suggest that a complete version of this should be
included in the "Backward compatibility" part of the PEP, as I
honestly don't really know how I'd write that without doing more
research. But such an example would make the KeyboardInterrupt case
seem more important than it is. Maybe if it's framed as "how to write
calling code that's compatible with older versions of Python but still
able to handle called code potentially raising exceptions that you
need to trap as part of a group", that would be a useful general
example.

Or maybe it's not actually something that will be needed that often.
I'm not sure - I'm trying to think in terms of pip, where we can't use
new features in our own code until we drop support for older versions,
but we might potentially rely on a library that uses exception
grouping internally on versions where it's available (and that code
lets those exception groups escape). It feels like a stretch to claim
this is particularly likely, but conversely it's something I can
easily imagine *could* happen...

Paul
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ITBRA7QAU64BN3XKBYV6G35NXKK2ESXX/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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 ExceptionGroups you need to update your code accordingly.
> If a library doesn't document that it raises ExceptionGroups and then one
> of those escapes, then that library has a bug. Just like with any other
> exception type.
>
> In my experience, libraries don't document what exceptions they raise
> very well. You can call that a bug, but it's a fact of life, I'm
> afraid. The problem here isn't so much that the library code now
> raises an exception that it used not to raise, but rather that *the
> user hitting Ctrl-C* can now result in a different exception surfacing
> in my code than it used to. Libraries don't re-wrap KeyboardInterrupt,
> as you pointed out in a previous response, so I can currently write
> code that traps KeyboardInterrupt, safe in the knowledge that by doing
> so I'll handle that user action properly. But with PEP 654, libraries
> might well (indeed, some libraries almost certainly will) start
> wrapping KeyboardInterrupt in an exception group. That's a backward
> incompatible change from the perspective of my code's interaction with
> the user, and I need to re-code my application to deal with it (and
> worse still, writing that new code in a way that is portable between
> versions is not particularly straightforward).
>

This is also true for MemoryError, and many other errors. What makes
KeyboardInterrupt special?


>
> > For older Pythons you would have to do something like
> >
> > except KeyboardInterrupt:
> >...
> > except BaseExceptionGroup:  # some stub type in old versions
> ># inspect the contents
> ># if there's a KeyboardInterrupt do what you need to do
> ># reraise the rest
>
> I'd be inclined to suggest that a complete version of this should be
> included in the "Backward compatibility" part of the PEP, as I
> honestly don't really know how I'd write that without doing more
> research. But such an example would make the KeyboardInterrupt case
> seem more important than it is. Maybe if it's framed as "how to write
> calling code that's compatible with older versions of Python but still
> able to handle called code potentially raising exceptions that you
> need to trap as part of a group", that would be a useful general
> example.


> Or maybe it's not actually something that will be needed that often.
> I'm not sure - I'm trying to think in terms of pip, where we can't use
> new features in our own code until we drop support for older versions,
> but we might potentially rely on a library that uses exception
> grouping internally on versions where it's available (and that code
> lets those exception groups escape). It feels like a stretch to claim
> this is particularly likely, but conversely it's something I can
> easily imagine *could* happen...



If a library starts raising ExceptionGroups from version 3.X it should
probably do that from a new API so people won't have to worry about it just
because they are bumping Python version. So I think the cross-version issue
is in the case of "I'm calling a user function and I don't know what it is
or what it raises", or the "I just want to write all exceptions to the log
and ignore them". So this is the "except Exception" case, which will work.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BF6R7Y6UAPSAFZYBQ2GKAMO7RJ6FYDAY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 651, Robust Stack Overflow Handling, Rejection notice

[Python Steering Council]

Hi Mark,

Thank you for submitting PEP 651. The Steering Council has spent the past two 
weeks reviewing PEP 651. After careful consideration, we have decided to reject 
the PEP. The following were the key points that led us to this decision:

* The benefits are not compelling enough. Deep recursion is not a common tool 
in  
  Python, and even with PEP 651 it would not be efficient enough to make it a 
common 
  tool.

* The benefit of PEP 651 is negated as soon as a non-Python function is 
involved in the 
  recursion, making the likelihood of it being useful even smaller. It also 
creates 
  easy pitfalls for users who do end up relying on recursion.

* We believe the PEP understates the disruption created by the technical 
solution of 
  multiple Python stack frames per C call. Although this may be solvable, it 
will 
  certainly cause substantial disruption to existing debuggers, tracers, and 
state 
  inspection tools as they need to adapt to this change (which may not be 
trivial).

* As the way to approach this will be platform-specific (as some parts of the 
proposal 
  are not portable), this can cause generic Python code to behave differently 
on   
  different platforms, making this kind of code less portable and less 
predictable.

In the end, the benefit of the PEP does not outweigh the cost of the potential 
breakage, confusion, and unpredictability of the feature.

With our appreciation,
The Python Steering Council
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/75BFSBM5AJWXOF5OSPLMJQSTP3TDOKRP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Sven R. Kunze]

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 BaseException). So ExceptionGroup 
is caught by "except Exception" or "except BaseException".


1) So I understand "try-except BaseException" (cf. concurrent.futures) 
will work without fixes (i.e. produce the same results).



BaseExceptionGroup is a subclass only of BaseException so it is caught 
by "except BaseException" but not "except Exception". And 
ExceptionGroup is allowed to wrap only Exceptions while BaseException 
can wrap Exceptions and and BaseExceptions. Makes sense?



2) Can you add motivating examples for "BaseExceptionGroup vs 
ExceptionGroup" in the PEP? Right now, I only see what the consequences 
are but not why it was done this way.


3) Can you explain (and show the reasoning behind) this automatic choice 
in the PEP? Sounds a bit like hidden magic to me.



Referring to: "The difference between them is that ExceptionGroup can 
only wrap Exception subclasses while BaseExceptionGroup can wrap any 
BaseException subclass. A factory method that inspects the nested 
exceptions and selects between ExceptionGroup and BaseExceptionGroup 
makes the choice automatic."



Best
Sven


PS:

the reason why I was a bit puzzled by the 
BaseExceptionGroup/ExceptionGroup issue is that:
- if it doesn't matter (so we do it automatically, because we do not 
want to bother anybody), why do we need ExceptionGroup at all, 
BaseExceptionGroup seems more flexible?
- if it does matter, why is the choice automatic and what if it was the 
wrong choice?


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4TEOPEX7EELLZUUFAODZ6XU7HF7FUE54/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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 process should exit" so you should not
usually handle them in your code. People use "except Exception" as a way to
"catch almost everything, but not the critical stuff like SystemExit".

If we make ExceptionGroup be a BaseException, then "except Exception"
doesn't catch it. So we make it a subclass of Exception. But then we can't
make it wrap things like SystemExit, which people expect will not be caught
by "except Exception".  So we add BaseExceptionGroup, which is a subclass
of BaseException and therefore is not caught by "except Exception", so it
can wrap SystemExit.

Why is the choice automated?  Because it can be. You look at what you're
wrapping. If it's all subclasses of Exception, then it can be
ExceptionGroup. If there are BaseExceptions, then it needs to be
BaseExceptionGroup. There is no reason to ever do anything else.

I hope that makes sense.


On Wed, Mar 3, 2021 at 7:32 PM Sven R. Kunze  wrote:

> 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 BaseException). So ExceptionGroup
> > is caught by "except Exception" or "except BaseException".
>
> 1) So I understand "try-except BaseException" (cf. concurrent.futures)
> will work without fixes (i.e. produce the same results).
>
>
> > BaseExceptionGroup is a subclass only of BaseException so it is caught
> > by "except BaseException" but not "except Exception". And
> > ExceptionGroup is allowed to wrap only Exceptions while BaseException
> > can wrap Exceptions and and BaseExceptions. Makes sense?
>
>
> 2) Can you add motivating examples for "BaseExceptionGroup vs
> ExceptionGroup" in the PEP? Right now, I only see what the consequences
> are but not why it was done this way.
>
> 3) Can you explain (and show the reasoning behind) this automatic choice
> in the PEP? Sounds a bit like hidden magic to me.
>
>
> Referring to: "The difference between them is that ExceptionGroup can
> only wrap Exception subclasses while BaseExceptionGroup can wrap any
> BaseException subclass. A factory method that inspects the nested
> exceptions and selects between ExceptionGroup and BaseExceptionGroup
> makes the choice automatic."
>
>
> Best
> Sven
>
>
> PS:
>
> the reason why I was a bit puzzled by the
> BaseExceptionGroup/ExceptionGroup issue is that:
> - if it doesn't matter (so we do it automatically, because we do not
> want to bother anybody), why do we need ExceptionGroup at all,
> BaseExceptionGroup seems more flexible?
> - if it does matter, why is the choice automatic and what if it was the
> wrong choice?
>
>
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JZJFDTZKPIY477EAVWHWEHLX2XFEAXJK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python Language Summit 2021 Signups Are Now Open

[Mariatta]

Sign up to Python Language Summit is still open for about 3 more weeks.

So far we received 32 sign ups, from 18 different regions, and 12 time
zones to work with.

We've only received 3 topics of discussions, and we definitely need more of
those.
If you have a topic to be discussed with Python core developers, please
fill in the forms linked in Łukasz's post.

I've made some infographics with these data, I will try to update it once
a day: https://mariatta.ca/language_summit_data/

We also have a page on PyCon US's website now:
https://us.pycon.org/2021/summits/language/

Thanks.

On Wed, Feb 24, 2021 at 9:54 AM Łukasz Langa  wrote:

> I’m happy to announce that we’ve opened the sign-up forms for the 2021
> Python Language Summit!
> TL;DR
>
>- When: Tuesday, May 11, 2021 (4 hours) and Wednesday, May 12, 2021 (4
>hours). Exact times TBD depending on attendee timezones.
>- Where: Online via Zoom (link will be sent via email to attendees)
>- Co-chairs: Mariatta Wijaya & Łukasz Langa
>- Blogger: Joanna Jablonski
>- Sign up to attend *and actively participate*:
>https://forms.gle/cgmGnmQMDhD2mhHY8 (closes after March 22nd, 2021 AoE)
>- Propose a topic: https://forms.gle/Jui9mxsHrB4fVvAB8 (closes after
>March 22nd, 2021 AoE)
>
> To get an idea of past Python Language Summits, you can read these blog
> posts:
>
>- 2020: Python Software Foundation News: The 2020 Python Language
>Summit
>
>- 2019:
>http://pyfound.blogspot.com/2019/05/the-2019-python-language-summit.html
>- 2018: The 2018 Python Language Summit [LWN.net]
>
>- 2017: The 2017 Python Language Summit [LWN.net]
>
>
> Do I need to sign up if I’m a Python core developer?
>
> Yes please! While in the past we have limited attendance to 50 people,
> this time, due to virtual format, we will be a bit more flexible, but will
> still keep it small and manageable. We aren’t planning to go beyond 80
> participants. Please register to reserve your space.
> Can I sign up if I’m not a Python core developer?
>
> Yes you can. In the past, we had quite a number of participants who were
> not Python core devs. Among them were maintainers and representatives from
> BeeWare, CircuitPython, PSF board member, PyCharm, PyPA, etc. Register if
> you want to participate. Note that until you hear back from us, your
> attendance is not confirmed. As explained in the question above, our
> “space” is more flexible than usual, but in the interest of maintaining a
> vigorous discussion space, we might still be unable to invite everyone who
> signs up.
> What kind of topics are covered?
>
> Python Language Summit is a special event with very specific audience:
> Python core developers. Ideally your topic is not an “announcement” or
> “project status” but rather something that will encourage further
> discussion and questions. The more controversial, the better. An open
> issue, group of issues, or a PEP that is awaiting decision are all good
> topics to propose. You can also further explain why this is better
> discussed in person instead of online.
>
> According to last year’s feedback, our audience prefer more discussions
> and shorter talks.
> Who can present a talk?
>
> Anyone, even if you’re not a Python core developer. However, please
> understand that we will have to be selective as space and time are limited.
> In particular, we are prioritizing active core contributors, as well as
> those who we believe will be able to improve the quality of the discussions
> at the event and bring a more diverse perspective to core Python
> developers. Note that your topic is not confirmed until you hear back from
> us.
> Code of Conduct
>
> PyCon’s Code of Conduct 
> applies and will be enforced.
>
> Thanks!
>
> @mariatta  & @ambv
> 
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5HBXSJ57UEADUU4HYT5CBLEBSQDTYTU5/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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:
>>
>> > 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 doesn't document that it raises ExceptionGroups and then one
>> of those escapes, then that library has a bug. Just like with any other
>> exception type.
>>
>> In my experience, libraries don't document what exceptions they raise
>> very well. You can call that a bug, but it's a fact of life, I'm
>> afraid. The problem here isn't so much that the library code now
>> raises an exception that it used not to raise, but rather that *the
>> user hitting Ctrl-C* can now result in a different exception surfacing
>> in my code than it used to. Libraries don't re-wrap KeyboardInterrupt,
>> as you pointed out in a previous response, so I can currently write
>> code that traps KeyboardInterrupt, safe in the knowledge that by doing
>> so I'll handle that user action properly. But with PEP 654, libraries
>> might well (indeed, some libraries almost certainly will) start
>> wrapping KeyboardInterrupt in an exception group. That's a backward
>> incompatible change from the perspective of my code's interaction with
>> the user, and I need to re-code my application to deal with it (and
>> worse still, writing that new code in a way that is portable between
>> versions is not particularly straightforward).
>>
>
> This is also true for MemoryError, and many other errors. What makes
> KeyboardInterrupt special?
>

Users get really grumpy if they can't stop a runaway program with ^C --
they want it to either terminate the script or app, or go back into the
toplevel REPL if there is one. And users write runaway code all the time.

asyncio in particular catches BaseException but excludes (reraises)
KeyboardInterrupt and SystemExit.

OTOH MemoryError is rarely a problem -- and Linux for example kills the
process rather than failing to allocate more memory, so you won't even get
an exception, so how it's treated by the exception machinery doesn't
matter. The MemoryErrors you do get tend to be recoverable, as in
'x'*1.

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4DDHVB3VSWEKPZABKO5C3LDFCPTQKRIN/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Greg Ewing]

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 cope"... And I have
to change *my* code to get the old contract back.


Seems to me this whole issue would go away if the ordinary
except statement were to look inside ExceptionGroups.

In other words, the only difference between except and
except* would be that multiple except* clauses can be run,
whereas only one except clause will run (the first one that
matches something in the ExceptionGroup).

Is there any good reason not to do things that way?

--
Greg
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NDIO4533M4OQZZWT65EKPPIXZU6ZJQUY/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Irit Katriel via Python-Dev]

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 code as long as
> > you don't let an exception group escape, and I'll cope"... And I have
> > to change *my* code to get the old contract back.
>
> Seems to me this whole issue would go away if the ordinary
> except statement were to look inside ExceptionGroups.
>
> In other words, the only difference between except and
> except* would be that multiple except* clauses can be run,
> whereas only one except clause will run (the first one that
> matches something in the ExceptionGroup).
>
> Is there any good reason not to do things that way?
>


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 "except T as e:") needs to be a
single naked exception. So if there is more than one match in the group we
would need to pick one (let's say the first in DFS order).

If we do this, then we have this situation. Before ExceptionGroups, you got
to choose which of the exceptions you have is the most important, and you
raised only that one. Now you raise a bunch of them and the order of the
except clauses in caller's code determines which one of them counts and
which ones are discarded. What do you make of that?

Irit
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O72A2J4HRHEKYBRL5NRL4YEUQVSL3TZQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Glenn Linderman]

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 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 cope"... And I
have
> to change *my* code to get the old contract back.

Seems to me this whole issue would go away if the ordinary
except statement were to look inside ExceptionGroups.

In other words, the only difference between except and
except* would be that multiple except* clauses can be run,
whereas only one except clause will run (the first one that
matches something in the ExceptionGroup).

Is there any good reason not to do things that way?



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 "except T as e:") needs to 
be a single naked exception. So if there is more than one match in the 
group we would need to pick one (let's say the first in DFS order).


If we do this, then we have this situation. Before ExceptionGroups, 
you got to choose which of the exceptions you have is the most 
important, and you raised only that one. Now you raise a bunch of them 
and the order of the except clauses in caller's code determines which 
one of them counts and which ones are discarded. What do you make of that?


You _could_ implement it as you said, but remember, you that with this 
idea, you are changing how except clauses work—so instead of making the 
order of the except clauses determine which one counts most, you could 
instead do something else.


One alternative idea would be to take the "first in DFS order" and see 
if it matches any of the except clauses, and if so, process that one.  
If not, then pick the next, and see if it matches, until one is found 
that matches, and can be processed.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WIED3DD3HMD4WBHVO2KCGFFCXSFM6UYU/
Code of Conduct: http://python.org/psf/codeofconduct/