El sáb, 27 mar 2021 a las 15:37, Guido van Rossum ()
escribió:
> Since my last post on the subject I have pretty much given up on PEP 649
> in favor of what we have in 3.10alpha6 -- annotations are always
> stringified. The two problems brought up by Joseph Perez in particular seem
> too thorny to
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
Since my last post on the subject I have pretty much given up on PEP 649 in
favor of what we have in 3.10alpha6 -- annotations are always stringified.
The two problems brought up by Joseph Perez in particular seem too thorny
to try and devise a solution for.
Jelle, could you explain why for your u
Hi Mark,
Reading that spec will take some time. Can you please summarize the
differences in English, in a way that is about as precise as PEP 634? I
have some comments inline below as well.
On Sat, Mar 27, 2021 at 10:16 AM Mark Shannon wrote:
> Hi Oscar,
>
> Thanks for the feedback.
>
> On 27/0
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 3/27/2021 4:06 AM, Serhiy Storchaka wrote:
26.03.21 20:37, Terry Reedy пише:
On 3/26/2021 6:29 AM, Marco Sulla wrote:
I would contribute to the project in my spare time. Can someone point
me to some easy task? I know C and the Python C API a little.
Review existing PRs. In some cases (ask
Hi Oscar,
Thanks for the feedback.
On 27/03/2021 4:19 pm, Oscar Benjamin wrote:
On Sat, 27 Mar 2021 at 13:40, Mark Shannon wrote:
Hi Mark,
Thanks for putting this together.
As the 3.10 beta is not so far away, I've cut down PEP 653 down to the
minimum needed for 3.10. The extensions wil
On Sat, 27 Mar 2021 at 13:40, Mark Shannon wrote:
>
Hi Mark,
Thanks for putting this together.
> As the 3.10 beta is not so far away, I've cut down PEP 653 down to the
> minimum needed for 3.10. The extensions will have to wait for 3.11.
>
> The essence of the PEP is now that:
>
> 1. The semant
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 Larry, I have the same question as Guido last month. I'd really like to
see some version of PEP 649 go into 3.10; is there anything I can do to
help? I opened https://github.com/larryhastings/co_annotations/issues/1 to
discuss what seems to be the main problem identified in the previous
discussi
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
Hi everyone,
As the 3.10 beta is not so far away, I've cut down PEP 653 down to the
minimum needed for 3.10. The extensions will have to wait for 3.11.
The essence of the PEP is now that:
1. The semantics of pattern matching, although basically unchanged, are
more precisely defined.
2. The
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
26.03.21 20:37, Terry Reedy пише:
> On 3/26/2021 6:29 AM, Marco Sulla wrote:
>> I would contribute to the project in my spare time. Can someone point
>> me to some easy task? I know C and the Python C API a little.
>
> Review existing PRs. In some cases (ask), convert existing patches
> posted on
17 matches
Mail list logo
