Hi Nathaniel,
Philosophy of Science 101: nobody knows what TheBestSolution is and nobody
ever will.
That said, when we decided to submit PEP 654, that was a point in time when
we came to believe that we found the right solution. We made significant
changes later following feedback we agreed with,
On Thu, May 6, 2021 at 2:17 AM Nathaniel Smith wrote:
>
> On Thu, Apr 29, 2021 at 9:14 AM Yury Selivanov
> wrote:
> > Nathaniel, at this point it's clear that this thread somehow does not
> > help us understand what you want. Could you please just write your own
> > PEP clearly outlining your pr
On Thu, Apr 29, 2021 at 9:14 AM Yury Selivanov wrote:
> Nathaniel, at this point it's clear that this thread somehow does not
> help us understand what you want. Could you please just write your own
> PEP clearly outlining your proposal, its upsides and downsides?
> Without a PEP from you this thr
Nathaniel Smith (in a conversation with Irit) wrote:
> ... suggested having each
> 'except Blah as exc' clause be executed once, receiving an
> ExceptionGroup containing all the Blah exceptions. Guido pointed out
> that this broke typing -- 'exc' would not longer have type 'Blah' --
> and I was li
On Wed, Apr 28, 2021 at 8:53 PM Nathaniel Smith wrote:
> Looking at the relevant section of the PEP again [1], it notes the
> same fatal flaw with my first suggestion, and then says that the
> multiple-except-executions option should be rejected because users
> have written code like 'except SomeE
On Fri, Apr 23, 2021 at 4:08 AM Irit Katriel wrote:
>
> On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith wrote:
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land.
>
> I'm very glad to hear that. It's been hard to know where you stand, because
> you didn't even decl
On Mon, Apr 26, 2021 at 2:27 PM Nathaniel Smith wrote:
> Yeah, you've understood correctly, and you see why I wrote "both the
> current proposal and the alternative have very complex implications
> and downsides" :-)
>
> [chomp lots of very helpful summarizing]
Gotcha, thanks!
ChrisA
___
On Fri, Apr 23, 2021 at 2:45 AM Chris Angelico wrote:
>
> On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote:
> > The main possibility that I don't think we've examined fully is to
> > make 'except' blocks fire multiple times when there are multiple
> > exceptions.
>
> Vanilla except blocks? N
On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith wrote:
> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compro
On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote:
>
> On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> > On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
> >> Sure. This was in my list of reasons why the backwards compatibility
> >> tradeoffs are forcing us into awkward compr
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
>> Sure. This was in my list of reasons why the backwards compatibility
>> tradeoffs are forcing us into awkward compromises. I only elaborated
>> on it b/c in your last email you said
On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
> On Tue, Apr 20, 2021 at 3:15 AM Irit Katriel
> wrote:
> > On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith wrote:
> >>
> >>
> >> The problem is that most of the time, even if you're using concurrency
> >> internally so multiple things *cou
On Wed, Apr 21, 2021 at 11:22 PM Nathaniel Smith wrote:
>
>
> Saying that you have to make a new API every time you start using
> concurrency inside a function is extremely restrictive.
You don't need a new API when you start using concurrency inside a
function. You need a new API when you star
On Tue, Apr 20, 2021 at 3:15 AM Irit Katriel wrote:
> On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith wrote:
>>
>>
>> The problem is that most of the time, even if you're using concurrency
>> internally so multiple things *could* go wrong at once, only one thing
>> actually *does* go wrong. So it
On Tue, Apr 20, 2021 at 2:15 PM srku...@mail.de wrote:
>
> So, forgive me my relatively simple mental model about ExceptionGroup. I
> still try to create one for daily use.
>
> As noted in the discussion, an EG provides a way to collect exceptions from
> different sources and raise them as a bun
On Wed, Apr 21, 2021 at 11:50 AM srku...@mail.de wrote:
>
> Removing two concepts and preserving semantics simplifies the matter for
> users. People need less to memorize and less to learn.
>
> Or am I missing something here? Couldn’t we achieve our goal without these
> two new classes?
No, we
Removing two concepts and preserving semantics simplifies the matter for users.
People need less to memorize and less to learn.
Or am I missing something here? Couldn’t we achieve our goal without these two
new classes?
Splitting, wrapping and exception handling semantics are perfectly fine and
I don’t see what this simplifies. We still need to implement split, and to
worry about wrapping or not wrapping BaseExceptions and we still need to define
exception handling semantics (except/except*).
> On 20 Apr 2021, at 22:12, srku...@mail.de wrote:
>
> So, forgive me my relatively simple
So, forgive me my relatively simple mental model about ExceptionGroup. I still
try to create one for daily use.
As noted in the discussion, an EG provides a way to collect exceptions from
different sources and raise them as a bundle. They have no apparent relation up
until this point in time (f
Hi Sven,
I don’t follow. What would the value of __group__ be and how would it work?
Irit
> On 20 Apr 2021, at 20:44, srku...@mail.de wrote:
>
>
> Hi Irit,
>
> reading this subthread specifically, I just got a wild idea and I couldn‘t
> find any related information in the PEP:
>
> Why not
Hi Irit,
reading this subthread specifically, I just got a wild idea and I couldn‘t find
any related information in the PEP:
Why not extending BaseException by __group__ among __cause__ and __context__?
Would this reduce some of the added complexity and thus increase broader
acceptance?
Cheer
On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith wrote:
>
> The problem is that most of the time, even if you're using concurrency
> internally so multiple things *could* go wrong at once, only one thing
> actually *does* go wrong. So it's unfortunate if some existing code is
> prepared for a spec
On Mon, Apr 5, 2021 at 9:48 AM Irit Katriel wrote:
> On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
>> - I'm uncomfortable with how in some contexts we treat EG's as placeholders
>> for the contained exceptions, and other places we treat them like a single
>> first-class exceptions. (Wi
Thomas and the rest of the SC,
Thank you for updating us and for your kind words about the PEP.
We agree that it is safer to include this in 3.11 and not rush it into
3.10. As you say, having time to develop the integration with asyncio
before finalizing the API will give us more confidence in th
Irit, Yury and Guido,
Thanks for submitting PEP 654 (Exception Groups and except *). The Steering
Council isn’t done debating this PEP, but we wanted to give an update so
everyone knows what to expect.
We are mostly in favour of the PEP, but we’re worried about the timing --
not just because ther
On Mon, Apr 5, 2021 at 2:59 PM Chris Jerdonek
wrote:
> This point reminded me again of this issue in the tracker ("Problems with
> recursive automatic exception chaining" from 2013):
> https://bugs.python.org/issue18861
> I'm not sure if it's exactly the same, but you can see that a couple of
> t
Just wanted to elaborate a little bit on StopIteration to add to Irit's reply:
On Mon, Apr 5, 2021 at 9:52 AM Irit Katriel via Python-Dev
wrote:
> On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
>> - There are a number of places where the Python VM itself catches exceptions
>> and has ha
Hi Nathaniel,
Thank you for your feedback. See a few comment below.
On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
> OK, better late than never... here's a much-delayed review of the PEP.
> Thank you Irit and Guido for carrying this forward while I've been AWOL!
> It's fantastic to see
On Mon, Apr 5, 2021 at 3:07 AM Nathaniel Smith wrote:
> - Recording pre-empted exceptions: This is another type of metadata that
> would be useful to print along with the traceback. It's non-obvious and a
> bit hard to explain, but multiple trio users have complained about this, so
> I assume it
OK, better late than never... here's a much-delayed review of the PEP.
Thank you Irit and Guido for carrying this forward while I've been AWOL!
It's fantastic to see my old design sketches turned into something like,
actually real.
== Overall feelings ==
Honestly, I have somewhat mixed feelings E
Hello,
On Sat, 27 Mar 2021 20:01:27 +
Irit Katriel wrote:
[]
> > you gentlemen come up with the "ultimate" way to deal with multiple
> > errors,
>
> I've been mistaken for a man before, but no-one has ever confused me
> for gentle. I'll take that as a compliment.
Sorry, was just a figure
Just a few comments to add to Irit's response.
On Sat, Mar 27, 2021 at 11:03 AM Paul Sokolovsky wrote:
[..]
> Bottom line: this seems like a Trio's special-purpose feature, with
> good wishes of becoming the de facto standard.
The bottom line is that Trio nurseries were proven to be a very usefu
On Sat, Mar 27, 2021 at 3:56 PM Greg Ewing
wrote:
> While we're talking about compelling use cases, does anyone have an
> actual, concrete use case for the proposed "except *" feature that's
> strong enough to justify new syntax?
>
> I'm fine with having ExceptionGroup as a built-in type. I'm not
Hi Greg,
If all you want is to catch an exception group and process it, then except*
does look like overkill.
It gets more interesting if you want to handle only some of the exceptions
and reraise the rest (without adding the current frame to the traceback),
or when the exception handler raises/r
While we're talking about compelling use cases, does anyone have an
actual, concrete use case for the proposed "except *" feature that's
strong enough to justify new syntax?
I'm fine with having ExceptionGroup as a built-in type. I'm not fine
with adding new syntax that will apparently be used on
Hi Paul,
On Sat, Mar 27, 2021 at 6:00 PM Paul Sokolovsky wrote:
>
> It definitely feels like a lot of effort went into devising and
> polishing ExceptionGroup's and except*, thanks. But I'm not sure if you
> gentlemen come up with the "ultimate" way to deal with multiple errors,
>
I've been mis
Hello,
On Sat, 27 Mar 2021 14:29:21 +
Irit Katriel wrote:
> Hi Paul,
>
> IIUC, you are saying that exception group should not be a builtin type
> because it is (1) complex (2) special-purposed. Instead, you
> propose that we make exception handling pluggable.
Yes, I wanted to mention tha
On Sun, 28 Mar 2021, 12:34 am Irit Katriel via Python-Dev, <
python-dev@python.org> wrote:
>
> Hi Paul,
>
> IIUC, you are saying that exception group should not be a builtin type
> because it is (1) complex (2) special-purposed. Instead, you propose that
> we make exception handling pluggable.
>
Hi Paul,
IIUC, you are saying that exception group should not be a builtin type
because it is (1) complex (2) special-purposed. Instead, you propose that
we make exception handling pluggable.
(1) I agree, it is somewhat complex - it took us several iterations to get
from the idea of "a containe
Hello,
On Sat, 27 Mar 2021 10:55:40 +
Irit Katriel wrote:
> One of the motivations for introducing ExceptionGroup as a builtin is
> so that we won't have a different custom version in each library that
> needs it. So if you are writing a library the needs to raise multiple
> exceptions, and
One of the motivations for introducing ExceptionGroup as a builtin is so
that we won't have a different custom version in each library that needs
it. So if you are writing a library the needs to raise multiple exceptions,
and then you decide to call Trio, you don't need to translate Trio's
MultiErr
Hello,
On Fri, 26 Mar 2021 16:19:26 -0700
Guido van Rossum wrote:
> Everyone,
>
> Given the resounding silence I'm inclined to submit this to the
> Steering Council. While I'm technically a co-author, Irit has done
> almost all the work, and she's done a great job. If there are no
> further iss
On Sat, 27 Mar 2021, 9:24 am Guido van Rossum, wrote:
> Everyone,
>
> Given the resounding silence I'm inclined to submit this to the Steering
> Council. While I'm technically a co-author, Irit has done almost all the
> work, and she's done a great job. If there are no further issues I'll send
>
On 3/26/2021 7:19 PM, Guido van Rossum wrote:
Everyone,
Given the resounding silence I'm inclined to submit this to the Steering
Council. While I'm technically a co-author, Irit has done almost all the
work, and she's done a great job. If there are no further issues I'll
send this SC-wards on
Everyone,
Given the resounding silence I'm inclined to submit this to the Steering
Council. While I'm technically a co-author, Irit has done almost all the
work, and she's done a great job. If there are no further issues I'll send
this SC-wards on Monday.
--Guido
On Sat, Mar 20, 2021 at 10:05 AM
45 matches
Mail list logo
