date:20210327

[Python-Dev] Re: Where and how can I contribute?

2021-03-27 Thread Serhiy Storchaka

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 bpo issues to PRs.

But before doing this ask if the original author want to create a PR.

___
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/QXWRSA5CWSELQSU36DGYFQUIQSJVHBHU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Paul Sokolovsky

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 issues I'll send this SC-wards on Monday.

One issue with PEP654 is that it introduces pretty adhoc and
complex-semantics concept (ExceptionGroup) on the language level.
Here's an idea (maybe duplicate) on how to introduce a much simpler,
and more generic concept on the language level, and let particular
frameworks to introduce (and elaborate without further changing the
language) adhoc concept they need.

So, let's look how the usual "except MyExc as e" works: it performs 
"isinstance(e0, MyExc)" operation, where e0 is incoming exception
(roughly, sys.exc_info[1]), and if it returns True, then assigns e0 to
the "e" variable and executes handler body. "isinstance(e0, MyExc)" is
formally known as an "exception filter".

As we see, currently Python hardcodes isinstance() as exception filter.
The idea is to allow to use an explicit exception filter. Let's reuse
the same "except *" syntax to specify it. Also, it's more flexible
instead of returning True/False from filter, to return either None
(filter didn't match), or an exception object to make available to
handler (which in general may be different than passed to the filter).
With this, ExceptionGroup usecases should be covered.

Examples:

1. Current implicit exception filter is equivalent to:

def implicit(e0, excs):  # one or tuple, as usual
if isinstance(e0, excs):
return e0
return None

try:
1/0
except *implicit(ZeroDivisionError) as e:
print(e)

2. Allow to catch main or chained exception (context manager example
from PEP)

def chained(e, excs):
while e:
if isinstance(e, excs):
return e
e = e.__cause__  # Simplified, should consider __context__ too

try:
tempfile.TemporaryDirectory(...)
except *chained(OSError) as e:
print(e)

3. Rough example of ExceptionGroup functionality (now not a language
builtin, just implemented by framework(s) which need it, or as a
separate module):

class ExceptionGroup:

...

@staticmethod
def match(e0, excs):
cur, rest = e0.split_by_types(excs)
# That's how we allow an exception handler to re-raise either an
# original group in full or just "unhandled" exception in the
# group (or anything) - everything should be passed via
# exception attributes (or computed by methods).
cur.org = e0
cur.rest = rest
return cur

try:
...
except *ExceptionGroup.match((TypeError, ValueError)) as e:
# try to handle a subgroup with (TypeError, ValueError) here
...
# now reraise a subgroup with unhandled exceptions from the
# original group
raise e.rest

> 
> --Guido
> 
> On Sat, Mar 20, 2021 at 10:05 AM Irit Katriel
>  wrote:
> 
> >
> > We would like to present for feedback a new version of PEP 654,
> > which incorporates the feedback we received in the discussions so
> > far: https://www.python.org/dev/peps/pep-0654/
> > The reference implementation has also been updated along with the
> > PEP.
> >
> > The changes we made since the first post are:
> >
> > 1. Instead of ExceptionGroup(BaseException), we will have two new
> > builtin types: BaseExceptionGroup(BaseException) and
> > ExceptionGroup(BaseExceptionGroup, Exception).
> > This is so that "except Exception" catches ExceptionGroups (but not
> > BaseExceptionGroups). BaseExceptionGroup.__new__ inspects the
> > wrapped exceptions, and if they are all Exception subclasses, it
> > creates an ExceptionGroup instead of a BaseExceptionGroup.
> >
> > 2. The exception group classes are not final - they can be
> > subclassed and split()/subgroup() work correctly if the subclass
> > overrides the derive() instance method as described here:
> > https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups
> >
> > 3. We had some good suggestions on formatting exception groups,
> > which we have implemented as you can see in the output shown for
> > the examples in the PEP.
> >
> > 4. We expanded the section on handling Exception Groups, to show how
> > subgroup can be used (with side effects) to do something for each
> > leaf exception, and how to iterate correctly when the tracebacks of
> > leaf exceptions are needed:
> > https://www.python.org/dev/peps/pep-0654/#handling-exception-groups
> >
> > 5. We expanded the sections on rationale and backwards
> > compatibility to explain our premise and expectations regarding how
> > exception groups will be used and how the transition to using them
> > will be managed.
> >
> > 6. We added several items to the rejected ideas section.
> >
> > We did not receive any comments (or make any changes) to the
> > proposed semantics of except*, hopefully this is because everyone
> > thought they are sen

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Irit Katriel via Python-Dev

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
MultiError into your own exception group type, because everybody uses the
builtin.   And your users don't need to learn how your particular exception
group works because they know that you are using the builtin one.

I see the aesthetic value of your suggestion, but does it have practical
advantages in light of the above?

Irit

On Sat, Mar 27, 2021 at 10:31 AM Paul Sokolovsky  wrote:

> 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 issues I'll send this SC-wards on Monday.
>
> One issue with PEP654 is that it introduces pretty adhoc and
> complex-semantics concept (ExceptionGroup) on the language level.
> Here's an idea (maybe duplicate) on how to introduce a much simpler,
> and more generic concept on the language level, and let particular
> frameworks to introduce (and elaborate without further changing the
> language) adhoc concept they need.
>
> So, let's look how the usual "except MyExc as e" works: it performs
> "isinstance(e0, MyExc)" operation, where e0 is incoming exception
> (roughly, sys.exc_info[1]), and if it returns True, then assigns e0 to
> the "e" variable and executes handler body. "isinstance(e0, MyExc)" is
> formally known as an "exception filter".
>
> As we see, currently Python hardcodes isinstance() as exception filter.
> The idea is to allow to use an explicit exception filter. Let's reuse
> the same "except *" syntax to specify it. Also, it's more flexible
> instead of returning True/False from filter, to return either None
> (filter didn't match), or an exception object to make available to
> handler (which in general may be different than passed to the filter).
> With this, ExceptionGroup usecases should be covered.
>
> Examples:
>
> 1. Current implicit exception filter is equivalent to:
>
> def implicit(e0, excs):  # one or tuple, as usual
> if isinstance(e0, excs):
> return e0
> return None
>
> try:
> 1/0
> except *implicit(ZeroDivisionError) as e:
> print(e)
>
> 2. Allow to catch main or chained exception (context manager example
> from PEP)
>
> def chained(e, excs):
> while e:
> if isinstance(e, excs):
> return e
> e = e.__cause__  # Simplified, should consider __context__ too
>
> try:
> tempfile.TemporaryDirectory(...)
> except *chained(OSError) as e:
> print(e)
>
> 3. Rough example of ExceptionGroup functionality (now not a language
> builtin, just implemented by framework(s) which need it, or as a
> separate module):
>
> class ExceptionGroup:
>
> ...
>
> @staticmethod
> def match(e0, excs):
> cur, rest = e0.split_by_types(excs)
> # That's how we allow an exception handler to re-raise either an
> # original group in full or just "unhandled" exception in the
> # group (or anything) - everything should be passed via
> # exception attributes (or computed by methods).
> cur.org = e0
> cur.rest = rest
> return cur
>
> try:
> ...
> except *ExceptionGroup.match((TypeError, ValueError)) as e:
> # try to handle a subgroup with (TypeError, ValueError) here
> ...
> # now reraise a subgroup with unhandled exceptions from the
> # original group
> raise e.rest
>
>
___
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/ZYMKRVYLUF7TWDWSCPXCRZFBDO3YOZMF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Paul Sokolovsky

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 then you decide to call Trio, you don't need to
> translate Trio's MultiError into your own exception group type,
> because everybody uses the builtin.

Looking from a different angle shows a different perspective:

1. Trio devised an interesting concept of "nurseries" to deal with
multiple tasks in asyncio-like programming.

2. It was all nice and beautiful until ... it came to error handling.
Note that it's a rather typical situation - one can write nice, clean,
beautiful code, which is not adequate in real-world scenarios,
particularly because of error handling concerns. Oftentimes, such
initial code/concepts are discarded, and more robust (though maybe not
as beautiful) concepts/code is used.

3. But that's not what happened in the Trio case. The concept of
nurseries got pushed forward, until it became clear that it requires
changes on the programming language level.

4. That's how PEP654 was born, which, besides async scheduling of
multiple tasks, bring *somewhat similar* usecases of e.g. raising
exceptions thru context managers' own exceptions.

Note that where errors and exceptions lead us is in questions on how to
handle them. And beyond a couple of well known patterns ("dump and
crash" or "dump and continue with next iteration"), error handling is
very adhoc to a particular application and particular error(s). Seen
from that angle, Trio wants to vendor-lock the entire language into its
particular (experimental) way of handling multiple errors.

So yes, maybe being well aware that you're handling exactly Trio's (or
asyncio's, or context manager's) error isn't bad thing actually. And if
it's clear that multiple asyncio frameworks are interested in sharing
common exception base class for such usecases, then it could be
introduced on the "asyncio" package level, or maybe even better, as a
module similar to "concurrent.futures".

> And your users don't need to
> learn how your particular exception group works because they know
> that you are using the builtin one.
> 
> I see the aesthetic value of your suggestion, but does it have
> practical advantages in light of the above?

The concern is that it codifies pretty complex and special-purpose
things on the language level. And it seems that the whole concept is
rather experimental and "original design". We can compare that with
another sufficiently complex feature which landed recently: pattern
matching. At all phases of the design and discussion of that feature,
one of the guiding principles was: "Many other languages implement it,
so we know it's generally useful, and have design space more or less
charted, and can vary things to find local optimum for Python".

Contrary to that, the original PEP654 didn't refer to (cross-language,
cross-framework) prior art in handling multiple errors, and I don't see
that changed in the latest version. So I'm sorry, but it seems like NIH
feature of a specific 3rd-party framework being promoted to a whole
language's way of doing things.

Under such circumstance, I guess it would be good idea to try to
decouple behavior of that feature from the languages core, and make
aspects of behavior more explicit (following "explicit is better than
implicit" principle), and allow to vary/evolve it without changing the
core language.

I tried to draft a scheme aspiring to allow that. (Which would
definitely need more work to achieve parity with functionality in
PEP654, because again, it tries to codify rather complex and "magic"
behavior. Where complex and magic behavior in exception handling is
itself of concern, so making it more explicit may be a good idea. (A
good "how other languages deal with it") review would mention that Go,
Rust, Zig, etc. don't have and condemn exception handling at all (normal
simple classy exceptions, not magic we discuss here!)).

Thanks,
Paul

> Irit
> 
> On Sat, Mar 27, 2021 at 10:31 AM Paul Sokolovsky 
> wrote:
> 
> > 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 issues I'll send this SC-wards on Monday.  
> >
> > One issue with PEP654 is that it introduces pretty adhoc and
> > complex-semantics concept (ExceptionGroup) on the language level.
> > Here's an idea (maybe duplicate) on how to introduce a much simpler,
> > and more generic concept on the language level, and let particular
> > frameworks to introduce (and elaborate without further changing the
> > language) adhoc concept they need.
> >
> > So, let's look how

[Python-Dev] Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

2021-03-27 Thread Mark Shannon


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 __match_kind__ special attribute will be used to determine which 
patterns to match, rather than relying on the collections.abc module.


Everything else has been removed or deferred.

The PEP now has only the slightest changes to semantics, which should be
undetectable in normal use. For those corner cases where there is a 
difference, it is to make pattern matching more robust.
E.g. With PEP 653, pattern matching will work in the collections.abc 
module. With PEP 634 it does not.



As always, all thoughts and comments are welcome.

Cheers,
Mark.
___
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/YYIT3QXMLPNLXQAQ5BCXE4LLJ57EE7JV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Irit Katriel via Python-Dev

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 container of exceptions" to something that works
correctly with split()/subgroup(), maintaining the integrity of
__traceback__/__cause__/__context__ information, allowing subclassing and
having a relatively simple API. To me this is a reason to provide it as a
builtin rather than a reason not to  (I think we should add this point to
the PEP- thanks).

You wrote:
> So yes, maybe being well aware that you're handling exactly Trio's (or
asyncio's, or context manager's) error isn't bad thing actually.

Maybe, in which case you can create a subclass of ExceptionGroup to mark
the groups coming from your library. But also maybe not, in which case you
don't have to.

(2) special-purposed? How so?   When I asked for a practical advantage of
your pluggable solution I meant an example of a use case that our proposal
doesn't accommodate well and where a pluggable one does better.
The only example you suggested so far was the TemporaryDirectory one, which
I don't find compelling:

  > > def chained(e, excs):
> > while e:
> > if isinstance(e, excs):
> > return e
> > e = e.__cause__  # Simplified, should consider __context__
> > too
> >
> > try:
> > tempfile.TemporaryDirectory(...)
> > except *chained(OSError) as e:
> > print(e)

What if the user code raised an OSError too, so now that exception group
has more than one? Even without that problem, why should I prefer this to
our proposal?

I am interested to know (1) what limitations you see in the ExceptionGroup
type we are proposing (in what sense is it special-purposed? what purpose
is it unsuitable for?) and (2) an example where the pluggable solution
works better.

Irit

On Sat, Mar 27, 2021 at 12:42 PM Paul Sokolovsky  wrote:

> 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 then you decide to call Trio, you don't need to
> > translate Trio's MultiError into your own exception group type,
> > because everybody uses the builtin.
>
> Looking from a different angle shows a different perspective:
>
> 1. Trio devised an interesting concept of "nurseries" to deal with
> multiple tasks in asyncio-like programming.
>
> 2. It was all nice and beautiful until ... it came to error handling.
> Note that it's a rather typical situation - one can write nice, clean,
> beautiful code, which is not adequate in real-world scenarios,
> particularly because of error handling concerns. Oftentimes, such
> initial code/concepts are discarded, and more robust (though maybe not
> as beautiful) concepts/code is used.
>
> 3. But that's not what happened in the Trio case. The concept of
> nurseries got pushed forward, until it became clear that it requires
> changes on the programming language level.
>
> 4. That's how PEP654 was born, which, besides async scheduling of
> multiple tasks, bring *somewhat similar* usecases of e.g. raising
> exceptions thru context managers' own exceptions.
>
> Note that where errors and exceptions lead us is in questions on how to
> handle them. And beyond a couple of well known patterns ("dump and
> crash" or "dump and continue with next iteration"), error handling is
> very adhoc to a particular application and particular error(s). Seen
> from that angle, Trio wants to vendor-lock the entire language into its
> particular (experimental) way of handling multiple errors.
>
> So yes, maybe being well aware that you're handling exactly Trio's (or
> asyncio's, or context manager's) error isn't bad thing actually. And if
> it's clear that multiple asyncio frameworks are interested in sharing
> common exception base class for such usecases, then it could be
> introduced on the "asyncio" package level, or maybe even better, as a
> module similar to "concurrent.futures".
>
> > And your users don't need to
> > learn how your particular exception group works because they know
> > that you are using the builtin one.
> >
> > I see the aesthetic value of your suggestion, but does it have
> > practical advantages in light of the above?
>
> The concern is that it codifies pretty complex and special-purpose
> things on the language level. And it seems that the whole concept is
> rather experimental and "original design". We can compare that with
> another sufficiently complex feature which landed recently: pattern
> matching. At all phases of the design and discussion of that feature,
> one of the guiding principles was: "Many other languages implement it,
> so we know it's generally useful,

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

2021-03-27 Thread Jelle Zijlstra

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

El jue, 4 feb 2021 a las 10:59, Guido van Rossum ()
escribió:

> Breaks are good. Looking forward to the next prototype!
>
> On Thu, Feb 4, 2021 at 10:45 AM Larry Hastings  wrote:
>
>>
>> After working on it and stressing out about it for some months, I decided
>> to take a break and scratch some other itches.  I'll return to PEP 649
>> soon, and I have every intention of having the PEP done and the prototype
>> done well in advance of 3.10b1--worry not.
>>
>> Thanks for checking in,
>>
>>
>> */arry*
>> On 2/4/21 9:17 AM, Guido van Rossum wrote:
>>
>> Hi Larry,
>>
>> Can you give us a status update for your PEP 649? I don't recall reading
>> anything about it in the past few weeks. I am super excited about this
>> solution to the problem (even if there are a few issues to work through)
>> and I think it will provide better backwards compatibility than the current
>> plan for Python 3.10 (PEP 563, from __future__ import annotations, causing
>> all annotations to be stringified).
>>
>> If we don't get this into 3.10, we'd have a much more complicated
>> transition. There are only two more alphas before 3.10b1 gets released! And
>> we'd have to get this approved by the Steering Council, which can take a
>> few weeks (cut them some slack, they have a big backlog). Fortunately you
>> already have an implementation that can be landed quickly once the PEP is
>> accepted.
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>> *Pronouns: he/him **(why is my pronoun here?)*
>> 
>>
>>
>
> --
> --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/IXIAUVSP62HMLCYY6RMALSETIU2UPIAQ/
> 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/G5L3OJMISIB5M3BRCVM6IOHA3HJYAL4E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Nick Coghlan

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

Note that (2) would be the *exact opposite* of the direction that we have
taken exception handling in general: it used to be far more permissive than
it is, and then got more restrictive over time to make structured exception
handling more consistent.

In particular, features like exception chaining and use case independent
trace back printing only work because exception consumers can rely on all
exceptions being instances of BaseException and having particular
double-underscore attributes like "cause", "context", and "traceback"

The lesson we've learned from Trio's experience is:

* regular exceptions are still fine for most purposes
* when they're not fine, they're not fine in a consistent way across a
variety of use cases where the existing exception machinery currently loses
or hides information, the problem isn't specific to Trio's nursery API

I understand the temptation to generalise, but a general proposal would
fail for the same reason the "user defined infix operators" PEPs failed:
despite decades of experience, there just weren't compelling use cases for
a general purpose feature. Instead, the proposal that succeeded was narrow:
it targeted the feature that people actually wanted (an infix operator for
matrix multiplication), rather than proposing more general machinery that
could be used to build that feature.

Cheers,
Nick.

>
___
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/PHCPGXZOMCT7X27QGWRTSYD6RSN2WOKL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

2021-03-27 Thread Oscar Benjamin

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 semantics of pattern matching, although basically unchanged, are
> more precisely defined.
>
> 2. The __match_kind__ special attribute will be used to determine which
> patterns to match, rather than relying on the collections.abc module.
>
> Everything else has been removed or deferred.

It would take me some time to compare exactly how this differs from
the current state after PEP 634 but I certainly prefer the
object-model based approach. It does seem that there are a lot of
permutations of how matching works but I guess that's just trying to
tie up all the different cases introduced in PEP 634.

> The PEP now has only the slightest changes to semantics, which should be
> undetectable in normal use. For those corner cases where there is a
> difference, it is to make pattern matching more robust.

Maybe I misunderstood but it looks to me as if this (PEP 653) changes
the behaviour of a mapping pattern in relation to extra keys. In PEP
634 extra keys in the target are ignored e.g.:

obj = {'a': 1, 'b': 2}
match(obj):
case {'a': 1}:
 # matches obj because key 'b' is ignored

In PEP 634 the use of **rest is optional if it is desired to catch the
other keys but does not affect matching. Here in PEP 653 there is the
pseudocode:

# A pattern not including a double-star pattern:
if $kind & MATCH_MAPPING == 0:
FAIL
if $value.keys() != $KEYWORD_PATTERNS.keys():
FAIL

My reading of that is that all keys would need to be match unless
**rest is used to absorb the others.

Is that an intended difference?

Personally I prefer extra keys not to be ignored by default so to me
that seems an improvement. If intentional then it should be listed as
another semantic difference though.

> E.g. With PEP 653, pattern matching will work in the collections.abc
> module. With PEP 634 it does not.

As I understood it this proposes that match obj: should use the class
attribute type(obj).__match_kind__ to indicate whether the object
being matched should be considered a sequence or a mapping or
something else rather than using isinstance(obj, Sequence) and
isinstance(obj, Mapping). Is there a corner case here where an object
can be both a Sequence and a Mapping? (How does PEP 634 handle that?)

Not using the Sequence and Mapping ABCs is good IMO. I'm not aware of
other core language features requiring the use of ABCs. In SymPy we
have specifically avoided them because they slow down isinstance
checking (this is measurable in the time taken to run the whole test
suite). Using the ABCs in PEP 634 seems surprising given that the
original pattern matching PEP actually listed the performance impact
of isinstance checks as part of the opening motivation. Maybe the ABCs
can be made faster but either way using them like this seems not in
keeping with the rest of the language.

Oscar
___
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/X7GJGGQRJQNS54RNBMXNI6A2K73JN4FJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

2021-03-27 Thread Mark Shannon

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 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 __match_kind__ special attribute will be used to determine which
patterns to match, rather than relying on the collections.abc module.

Everything else has been removed or deferred.

It would take me some time to compare exactly how this differs from
the current state after PEP 634 but I certainly prefer the
object-model based approach. It does seem that there are a lot of
permutations of how matching works but I guess that's just trying to
tie up all the different cases introduced in PEP 634.

The PEP now has only the slightest changes to semantics, which should be
undetectable in normal use. For those corner cases where there is a
difference, it is to make pattern matching more robust.

Maybe I misunderstood but it looks to me as if this (PEP 653) changes
the behaviour of a mapping pattern in relation to extra keys. In PEP
634 extra keys in the target are ignored e.g.:

obj = {'a': 1, 'b': 2}
match(obj):
case {'a': 1}:
# matches obj because key 'b' is ignored

In PEP 634 the use of **rest is optional if it is desired to catch the
other keys but does not affect matching. Here in PEP 653 there is the
pseudocode:

# A pattern not including a double-star pattern:
if $kind & MATCH_MAPPING == 0:
FAIL
if $value.keys() != $KEYWORD_PATTERNS.keys():
FAIL

I missed that when updating the PEP, thanks for pointing it out.
It should be the same as for double-star pattern:

if not $value.keys() >= $KEYWORD_PATTERNS.keys():
FAIL

I'll update the PEP.

My reading of that is that all keys would need to be match unless
**rest is used to absorb the others.

Is that an intended difference?

Personally I prefer extra keys not to be ignored by default so to me
that seems an improvement. If intentional then it should be listed as
another semantic difference though.

I don't have a strong enough opinion either way.
I can see advantages to both ways of doing it.

E.g. With PEP 653, pattern matching will work in the collections.abc
module. With PEP 634 it does not.

As I understood it this proposes that match obj: should use the class
attribute type(obj).__match_kind__ to indicate whether the object
being matched should be considered a sequence or a mapping or
something else rather than using isinstance(obj, Sequence) and
isinstance(obj, Mapping). Is there a corner case here where an object
can be both a Sequence and a Mapping? (How does PEP 634 handle that?)

If you define a class as a subclass of both collections.abc.Sequence and
collections.abc.Mapping, then PEP 634 will treat it as both sequence and
mapping, meaning it has to try every pattern. That prevents the
important (IMO) optimization of checking the kind only once.

Cheers,
Mark.

Not using the Sequence and Mapping ABCs is good IMO. I'm not aware of
other core language features requiring the use of ABCs. In SymPy we
have specifically avoided them because they slow down isinstance
checking (this is measurable in the time taken to run the whole test
suite). Using the ABCs in PEP 634 seems surprising given that the
original pattern matching PEP actually listed the performance impact
of isinstance checks as part of the opening motivation. Maybe the ABCs
can be made faster but either way using them like this seems not in
keeping with the rest of the language.

Oscar

___
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/WCN3P4XYVWGL4UTEHNYO2LJO5ULZY3GI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where and how can I contribute?

2021-03-27 Thread Terry Reedy


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), convert existing patches
posted on bpo issues to PRs.


But before doing this ask if the original author want to create a PR.


Asking includes asking any core devs on the issue whether they have 
rejected a particular patch or are interested in possibly merging it 
either as is or with describable changes.


For IDLE issues, I have already asked and gotten approval from most 
authors of pending attached diffs.



--
Terry Jan Reedy


___
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/LTJEEIENLMRQXZG2SPUAP7YGWEP26S6R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Paul Sokolovsky

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 that alternative possibility. I have to admit
that I haven't read the entire discussion of the PEP, but the messages
I read oftentimes were over-optimistic about the feature, rather than
considering its issues/possible alternatives. 

> (1) I agree, it is somewhat complex - it took us several iterations
> to get from the idea of "a container of exceptions" to something that
> works correctly with split()/subgroup(), maintaining the integrity of
> __traceback__/__cause__/__context__ information, allowing subclassing
> and having a relatively simple API. To me this is a reason to provide
> it as a builtin rather than a reason not to  (I think we should add
> this point to the PEP- thanks).

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,
which deserves being codified on the language level (vs be added as
pluggable means indeed). That's why I asked if there's any prior art of
a similar solution(s) in other languages and/or systems - that would
definitely sooth concerns and add credibility.

(And I'm not saying that Python can't lead there - just that more
sustainable way would be to try and make it more generic/explicit rather
than fix on a particular novel solution right away.) 

> You wrote:
> > So yes, maybe being well aware that you're handling exactly Trio's
> > (or  
> asyncio's, or context manager's) error isn't bad thing actually.
> 
> Maybe, in which case you can create a subclass of ExceptionGroup to
> mark the groups coming from your library. But also maybe not, in
> which case you don't have to.
> 
> (2) special-purposed? How so?   When I asked for a practical
> advantage of your pluggable solution I meant an example of a use case
> that our proposal doesn't accommodate well and where a pluggable one
> does better. The only example you suggested so far was the
> TemporaryDirectory one, which I don't find compelling:

That's the impression I've got from reading the "Motivation" section.
It cites Trio and multiple errors from async tasks as the guiding
usecase. It also mentions a couple of cases in the stdlib, where my
personal impression is that a simpler mechanism would suffice. Then it
also cites some 3rd-party libs and their maintainers, who say such
thing *might* be useful. But it's going to take practice to see if the
actual thing added is useful. What if other projects turn out
to want something slightly different (e.g. simpler?). Oh, they won't
have much choice (to complain), as it's already shipped to them, not
even in the stdlib, but in the language!

Bottom line: this seems like a Trio's special-purpose feature, with
good wishes of becoming the de facto standard. I find that somewhat
ironical, as Trio's original motivation was to explore alternative ways
of doing async framework in Python. And now it hardcodes its way of
dealing with multiple errors in the language (no more exploration and
alternatives).

>   > > def chained(e, excs):
> > > while e:
> > > if isinstance(e, excs):
> > > return e
> > > e = e.__cause__  # Simplified, should consider __context__
> > > too
> > >
> > > try:
> > > tempfile.TemporaryDirectory(...)
> > > except *chained(OSError) as e:
> > > print(e)  
> 
> What if the user code raised an OSError too, so now that exception
> group has more than one? 

I don't see how that's different from PEP654's ExceptionGroup's case.
It's just in ExceptionGroup, there would be 2 (unrelated?) OSError's,
while using normal chaining rules, there's at least context info which
is preserved.

> Even without that problem, why should I
> prefer this to our proposal?

My idea was to show an alternative not mentioned in PEP654's "Rejected
Ideas" section.

> I am interested to know (1) what limitations you see in the
> ExceptionGroup type we are proposing (in what sense is it
> special-purposed? 

Just as a specific example, what if my application indeed needs
ExceptionGroup's (and not just more flexible matching of existing
exception chains), but I want it to be a bit simpler: a) to have a flat
structure of contained exceptions; b) want to actually emphasize the
users that they should not rely on the ordering, so want it to be a set.

My understanding is that ExceptionGroup is carefully designed to allow
subclassing it and override behavior, and the above should be possible
by subclassing. But usually, a simpler base class is subclassed to have
more advanced/complex behavior. So again, current ExceptionGroup feels
kind of specialized with its careful attention to hierarchy and
multi-story "3D" traceback

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Irit Katriel via Python-Dev

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 mistaken for a man before, but no-one has ever confused me for
gentle. I'll take that as a compliment.


> which deserves being codified on the language level (vs be added as
> pluggable means indeed).



Pluggable is not without its problems. I'm all in favor of you developing
this idea and proposing an alternative.
As I said before, you just need to answer two questions:
1. show a limitation of our approach  (the contrived flat-set is not one -
see below)
2. describe how a pluggable approach works for that case


> >   > > def chained(e, excs):
> > > > while e:
> > > > if isinstance(e, excs):
> > > > return e
> > > > e = e.__cause__  # Simplified, should consider __context__
> > > > too
> > > >
> > > > try:
> > > > tempfile.TemporaryDirectory(...)
> > > > except *chained(OSError) as e:
> > > > print(e)
> >
> > What if the user code raised an OSError too, so now that exception
> > group has more than one?
>
> I don't see how that's different from PEP654's ExceptionGroup's case.
> It's just in ExceptionGroup, there would be 2 (unrelated?) OSError's,
> while using normal chaining rules, there's at least context info which
> is preserved.
>

It's different because your "match" function returns a single exception
(the first one that is of OSError type). Any further OSErrors will be
reraised.  The PEP's except* knows how to match multiple exceptions of the
relevant type.


>
> > I am interested to know (1) what limitations you see in the
> > ExceptionGroup type we are proposing (in what sense is it
> > special-purposed?
>
> Just as a specific example, what if my application indeed needs
> ExceptionGroup's (and not just more flexible matching of existing
> exception chains), but I want it to be a bit simpler: a) to have a flat
> structure of contained exceptions; b) want to actually emphasize the
> users that they should not rely on the ordering, so want it to be a set.
>
> My understanding is that ExceptionGroup is carefully designed to allow
> subclassing it and override behavior, and the above should be possible
> by subclassing.



Indeed:

class PaulsExceptionGroup(ExceptionGroup):
def __new__(cls, message, excs):
for e in excs:
if isinstance(e, BaseExceptionGroup):
raise TypeError("me is a flat exception group")
return super().__new__(cls, message, excs)

@property
def exceptions(self):
return set(super().exceptions)

def derive(self, excs):
return PaulsExceptionGroup(self.message, excs)


eg1 = PaulsExceptionGroup("Paul's group", [ValueError(12),
TypeError(42)])
print(repr(eg1))
print(eg1.exceptions)

match, rest = eg1.split(ValueError)
print(f'{match=!r}\n{rest=!r}')
print(f'{match.exceptions=}\n{rest.exceptions=}')

Output:
PaulsExceptionGroup("Paul's group", [ValueError(12), TypeError(42)])
{TypeError(42), ValueError(12)}
match=PaulsExceptionGroup("Paul's group", [ValueError(12)])
rest=PaulsExceptionGroup("Paul's group", [TypeError(42)])
match.exceptions={ValueError(12)}
rest.exceptions={TypeError(42)}



 See - split() just works for you out of the box.


But usually, a simpler base class is subclassed to have
> more advanced/complex behavior. So again, current ExceptionGroup feels
> kind of specialized with its careful attention to hierarchy and
> multi-story "3D" tracebacks.


So your concern with our design is that ExceptionGroup implements a generic
split() that handles tracebacks and nested structure correctly, and you
might not need that because maybe you don't nest or you don't care about
tracebacks?

If that is the case then I think you are confusing "generic" with
"special-purpose". ExceptionGroup is generic, it works for general nested
groups with arbitrary tracebacks and cause/context.  That's the opposite of
special-purpose.

 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/SKIJ7ZG6AF2UFXBCGYAODX4F6M3GSPPP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

2021-03-27 Thread Guido van Rossum

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/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 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 __match_kind__ special attribute will be used to determine which
> >> patterns to match, rather than relying on the collections.abc module.
> >>
> >> Everything else has been removed or deferred.
> >
> > It would take me some time to compare exactly how this differs from
> > the current state after PEP 634 but I certainly prefer the
> > object-model based approach. It does seem that there are a lot of
> > permutations of how matching works but I guess that's just trying to
> > tie up all the different cases introduced in PEP 634.
>

It would be simpler if this was simply an informational PEP without
proposing new features -- then we wouldn't have to rush.

You could then propose the new __match_kind__ attribute in a separate PEP,
written more in the style of PEP 634, without pseudo code.

I find it difficult to wrap my head around the semantics of __match_kind__
because it really represents a few independent flags (with some
constraints) but all the text is written using explicit, hard-to-read
bitwise and/or operations. Let me give it a try.

- Let's call the four flag bits by short names: SEQUENCE, MAPPING, DEFAULT,
SELF.

SEQUENCE and MAPPING are for use when an instance of a class appears in the
subject position (i.e., for `match x`, we look for these bits in
`type(x).__match_kind__`). Neither of these is set by default. At most one
of them should be set.

- If SEQUENCE is set, the subject is treated like a sequence (this is set
for list, tuple and other sequences, but not for str, bytes and bytearray).

- Similarly, MAPPING means the subject should be treated as a mapping, and
is set for dict and other mapping types.

The DEFAULT and SELF flags are for use when a class is used in a class
pattern (i.e., for `case cls(...)` we look for these bits in
`cls.__match_kind__`). At most one of these should be set. DEFAULT is set
on class `object` and anything that doesn't explicitly clear it.

- If DEFAULT is set, semantics of PEP 634 apply except for the special
behavior enabled by the SELF flag.

- If SELF is set, `case cls(x)` binds the subject to x, and no other forms
of `case cls(...)` are allowed.

- If neither DEFAULT nor SELF is set, `case cls(...)` does not take
arguments at all.

Please correct any misunderstandings I expressed here! (And please include
some kind of summary like this in your PEP.)

Also, I think that we should probably separate this out in two separate
flag sets, one for subjects and one for class patterns -- it is pretty
confusing to merge the flag sets into a single value when their
applicability (subject or class pattern) is so different.

> >> The PEP now has only the slightest changes to semantics, which should be
> >> undetectable in normal use. For those corner cases where there is a
> >> difference, it is to make pattern matching more robust.
> >
> > Maybe I misunderstood but it looks to me as if this (PEP 653) changes
> > the behaviour of a mapping pattern in relation to extra keys. In PEP
> > 634 extra keys in the target are ignored e.g.:
> >
> > obj = {'a': 1, 'b': 2}
> > match(obj):
> >  case {'a': 1}:
> >   # matches obj because key 'b' is ignored
> >
> > In PEP 634 the use of **rest is optional if it is desired to catch the
> > other keys but does not affect matching. Here in PEP 653 there is the
> > pseudocode:
> >
> > # A pattern not including a double-star pattern:
> > if $kind & MATCH_MAPPING == 0:
> >  FAIL
> > if $value.keys() != $KEYWORD_PATTERNS.keys():
> >  FAIL
>
> I missed that when updating the PEP, thanks for pointing it out.
> It should be the same as for double-star pattern:
>
>  if not $value.keys() >= $KEYWORD_PATTERNS.keys():
>  FAIL
>
> I'll update the PEP.
>
> >
> > My reading of that is that all keys would need to be match unless
> > **rest is used to absorb the others.
> >
> > Is that an intended difference?
> >
> > Personally I prefer extra keys not to be ignored by default so to me
> > that seems an improvement. If intentional then it should be listed as
> > another semantic difference though.
>
> I don't have a strong enough opinion either way.
> I can see advantages to both ways of doing it.
>

Let's not change this. We carefully discussed and c

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

2021-03-27 Thread Guido van Rossum

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 use cases PEP 649 is preferred over
PEP 563?

On Sat, Mar 27, 2021 at 7:35 AM Jelle Zijlstra 
wrote:

> 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
> discussion.
>
> El jue, 4 feb 2021 a las 10:59, Guido van Rossum ()
> escribió:
>
>> Breaks are good. Looking forward to the next prototype!
>>
>> On Thu, Feb 4, 2021 at 10:45 AM Larry Hastings 
>> wrote:
>>
>>>
>>> After working on it and stressing out about it for some months, I
>>> decided to take a break and scratch some other itches.  I'll return to PEP
>>> 649 soon, and I have every intention of having the PEP done and the
>>> prototype done well in advance of 3.10b1--worry not.
>>>
>>> Thanks for checking in,
>>>
>>>
>>> */arry*
>>> On 2/4/21 9:17 AM, Guido van Rossum wrote:
>>>
>>> Hi Larry,
>>>
>>> Can you give us a status update for your PEP 649? I don't recall reading
>>> anything about it in the past few weeks. I am super excited about this
>>> solution to the problem (even if there are a few issues to work through)
>>> and I think it will provide better backwards compatibility than the current
>>> plan for Python 3.10 (PEP 563, from __future__ import annotations, causing
>>> all annotations to be stringified).
>>>
>>> If we don't get this into 3.10, we'd have a much more complicated
>>> transition. There are only two more alphas before 3.10b1 gets released! And
>>> we'd have to get this approved by the Steering Council, which can take a
>>> few weeks (cut them some slack, they have a big backlog). Fortunately you
>>> already have an implementation that can be landed quickly once the PEP is
>>> accepted.
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>> *Pronouns: he/him **(why is my pronoun here?)*
>>> 
>>>
>>>
>>
>> --
>> --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/IXIAUVSP62HMLCYY6RMALSETIU2UPIAQ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>

-- 
--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/26EADAQM5CTPDWUSZ4EIMCEYZV2VTQEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

2021-03-27 Thread Greg Ewing


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 only in rare
circumstances.

Can code that's aware of the possibility of getting an ExceptionGroup
not simply catch it as a normal exception and then pick it apart? Do
we really need a whole new piece of machinery for this?

--
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/EIW6JGXRWKEEIY72CGZ7BMKU3LHJIZQK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

2021-03-27 Thread Jelle Zijlstra

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 try and devise a solution for.
>
> Jelle, could you explain why for your use cases PEP 649 is preferred over
> PEP 563?
>
> The static(ish) type checker we use internally,
https://github.com/quora/pyanalyze, relies on the runtime `__annotations__`
object to get types. I also support getting types out of string
annotations, but it would make my life simpler if `__annotations__` worked
like in PEP 649 so I wouldn't have to worry about scoping.

Consider code like this:

def make_function(return_type):
def f() -> return_type:
pass
return f

int_func = make_function(int)

Currently, I can look at int_func.__annotations__ and see that the return
type is int, but with stringified annotations it's just "return_type" and I
have no way to get int out.

Now, PEP 649 doesn't actually fix this at the moment, since it still
resolves all annotations in the global scope, but that's easily fixed by
removing the special case in
https://github.com/larryhastings/co_annotations/blob/co_annotations/Python/compile.c#L3815
.

> On Sat, Mar 27, 2021 at 7:35 AM Jelle Zijlstra 
> wrote:
>
>> 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
>> discussion.
>>
>> El jue, 4 feb 2021 a las 10:59, Guido van Rossum ()
>> escribió:
>>
>>> Breaks are good. Looking forward to the next prototype!
>>>
>>> On Thu, Feb 4, 2021 at 10:45 AM Larry Hastings 
>>> wrote:
>>>

 After working on it and stressing out about it for some months, I
 decided to take a break and scratch some other itches.  I'll return to PEP
 649 soon, and I have every intention of having the PEP done and the
 prototype done well in advance of 3.10b1--worry not.

 Thanks for checking in,

 */arry*
 On 2/4/21 9:17 AM, Guido van Rossum wrote:

 Hi Larry,

 Can you give us a status update for your PEP 649? I don't recall
 reading anything about it in the past few weeks. I am super excited about
 this solution to the problem (even if there are a few issues to work
 through) and I think it will provide better backwards compatibility than
 the current plan for Python 3.10 (PEP 563, from __future__ import
 annotations, causing all annotations to be stringified).

 If we don't get this into 3.10, we'd have a much more complicated
 transition. There are only two more alphas before 3.10b1 gets released! And
 we'd have to get this approved by the Steering Council, which can take a
 few weeks (cut them some slack, they have a big backlog). Fortunately you
 already have an implementation that can be landed quickly once the PEP is
 accepted.

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

>>>
>>> --
>>> --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/IXIAUVSP62HMLCYY6RMALSETIU2UPIAQ/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>
> --
> --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/IS4H2UVCZ42P4GVH3M2MVFYJHOMJPA4I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Where and how can I contribute?

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Python-Dev] Re: Where and how can I contribute?

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

[Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]

[Python-Dev] Re: Status of PEP 649 -- Deferred Evaluation Of Annotations Using Descriptors

17 matches

Site Navigation

Mail list logo

Footer information