[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Larry Hastings]

On 8/9/21 8:25 PM, Inada Naoki wrote:

Currently, reference implementation of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.


Perhaps this sounds strange--but I don't actually agree.

PEP 563 was proposed to solve a forward-references problem for the 
typing community.  If you read the PEP, you'll note it contains no 
discussion about its impact on CPU performance or memory consumption.  
The performance of its prototype was fine, and in any case, the 
important thing was to solve the problem in the language.


I think PEP 649 should be considered in the same way.  In my opinion, 
the important thing is to figure out what semantics we want for the 
language.  Once we figure out what semantics we want, we should 
implement them, and only /then/ should we start worrying about 
performance.  Fretting about performance at this point is premature and 
a distraction.


I assert PEP 649's performance and memory use is already acceptable, 
particularly for a prototype.  And I'm confident that if PEP 649 is 
accepted, the core dev community will find endless ways to optimize the 
implementation.




As far as I remember, the reference implementation created a function
object for each methods.


First, it's only for methods with annotations.  Second, it only stores a 
code object on the annotated function; the co_annotations function is 
lazily created.  The exception to this is when co_annotations needs a 
closure; in that case, it currently creates and binds the co_annotation 
function non-lazily.  Obviously this could be done lazily too, I didn't 
bother for the prototype.



//arry/

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Thomas Grainger]

What about using a coroutine of `v = yield (name, scope)` so the caller can 
choose how and when names are resolved?
___
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/RDQXLGRLCF6OWLU5ANDUSXJURNMKCIBL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Larry Hastings]

On 8/10/21 11:15 AM, Thomas Grainger wrote:

Although the co_annoations code could intercept the NameError and replace 
return a ForwardRef object instead of the resolved name



No, it should raise a NameError, just like any other Python code.  
Annotations aren't special enough to break the rules.


I worry about Python-the-language enshrining design choices made by the 
typing module.  Python is now on its fourth string interpolation 
technology, and it ships with three command-line argument parsing 
libraries; in each of these cases, we were adding a New Thing that was 
viewed at the time as an improvement over the existing thing(s).  It'd 
be an act of hubris to assert that the current "typing" module is the 
ultimate, final library for expressing type information in Python.  But 
if we tie the language too strongly to the typing module, I fear we 
could strangle its successors in their cribs.



//arry/

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Larry Hastings]

On 8/10/21 11:09 AM, Damian Shaw wrote:
Could PEP 649 be modified to say that if a NameError is raised the 
result is not cached and therefore you can inspect it later at runtime 
to get the real type once it is defined? Wouldn't that then allow 
users to write code that allows for all use cases under this scenario?



The PEP doesn't say so explicitly, but that was the intent of the 
design, yes.  If you look at the pseudo-code in the "__co_annotations__" 
section:


   https://www.python.org/dev/peps/pep-0649/#co-annotations

you'll see that it doesn't catch NameError, allowing it to bubble up to 
user code.  The prototype intentionally behaves the same way.  Certainly 
it wouldn't hurt to mention that explicitly in the PEP.



//arry/

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

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[Christopher Barker]

On Tue, Aug 10, 2021 at 3:00 PM  wrote:

> The history of bytes/bytearray is a dual-purpose view.  It can be used in
> a string-like way to emulate Python 2 string handling (hence all the usual
> string methods and a repr that displays in a string-like fashion).  It can
> also be used as an array of numbers, 0 to 255 (hence the list methods and
> having an iterator of ints).  ISTM that the authors of this PEP reject or
> want to discourage the latter use cases.
>

I didn't read it that way, but if so, please no, I"d rather see the former
use cases discouraged. ISTM that the Py2 string handling is still needed
for working with mixed binary / text data -- but that should be a pretty
specialized use case. spelling the way to create a byte, byte() sure makes
more sense in any other context.


> ... anything where a C programmer would an array of unsigned chars).
>

or any programmer would use an array of unsigned 8bit integers :-) numpy
spells it: `np.uint8`, and the the type in the C99 stdint.h is `uint8_t`.
My point is that for anyone not an "old time" C programmer, or even a
Python2 programmer, the  "character is an unsigned 8 bit int" concept is
alien and confusing, not a helpful mnemonic.


> For example, creating a single byte with bytes([0x1f]) isn't pleasant,
> obvious, or fast.
>

no, though bytes([31]) isn't horrible ;-)   (despite coding for over four
decades, I'm still not comfortable with hex notation)

I say it's not horrible, because bytes is a Sequence of bytes (or integer
values between 0 and 255), initializing it with an iterable seems pretty
reasonable, that's how we initialize most (all?) other sequences after all.
And compatible with array.array and numpy arrays.

-CHB


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/RM4JHK4GIKYYWV7J5F6IQJ66KUIXWMMF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[raymond . hettinger]

I recommend removing the "discouragement" from writing "bytes(10)".  That is 
merely stylistic.  As long as we support the API, it is valid Python.  In the 
contexts where it is currently used, it tends to be clear about what it is 
doing:  buffer = bytearray(bufsize). That doesn't need to be discouraged.

Also, I concur the with SC comment that the singular of bytearray() or bytes() 
is byte(), not bchr().  Practically what people want here is an efficient 
literal that is easier to write than:  b'\x1F'.   I don't think bchr() meets 
that need. Neither bchr(0x1f) or bytearray.fromint(0x1f) are fast (not a 
literal) nor are they easier to read or type.

The history of bytes/bytearray is a dual-purpose view.  It can be used in a 
string-like way to emulate Python 2 string handling (hence all the usual string 
methods and a repr that displays in a string-like fashion).  It can also be 
used as an array of numbers, 0 to 255 (hence the list methods and having an 
iterator of ints).  ISTM that the authors of this PEP reject or want to 
discourage the latter use cases.  

This is disappointing because often the only reasonable way to manipulate 
binary data is with bytearrays.  A user could switch to array.array() or a 
numpy.array, but that is unnecessarily inconvenient given that we already have 
a nice builtin type that means the need (for images, crypto hashes, 
compression, bloom filters, or anything where a C programmer would an array of 
unsigned chars).

Given that bytes/bytearray is already an uncomfortable hybrid of string and 
list APIs for binary data, I don't think the competing views and APIs will be 
disentangled by adding methods that duplicate functionality that already 
exists.   Instead, I recommend that the PEP focus on one or two cases where 
methods could be added that simplify any common tasks that are currently 
awkward.  For example, creating a single byte with bytes([0x1f]) isn't 
pleasant, obvious, or fast.
___
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/OKILIXKK7F6BHDRTFRGUFXXUDNNZW3BL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Guido van Rossum]

On Tue, Aug 10, 2021 at 11:41 AM Jelle Zijlstra 
wrote:

>
>
> El mar, 10 ago 2021 a las 11:20, Thomas Grainger ()
> escribió:
>
>> Although the co_annoations code could intercept the NameError and replace
>> return a ForwardRef object instead of the resolved name
>>
> I implemented a version of this in
> https://github.com/larryhastings/co_annotations/pull/3 but Larry didn't
> like it.
>

However, I do like it, despite all Larry's arguing against it.

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Thomas Grainger]

Jelle Zijlstra wrote:
> El mar, 10 ago 2021 a las 11:20, Thomas Grainger (tagr...@gmail.com)
> escribió:
> > Although the co_annoations code could intercept the NameError and replace
> > return a ForwardRef object instead of the resolved name
> > I implemented a version of this in
> https://github.com/larryhastings/co_annotations/pull/3 but Larry didn't
> like it.
> > 
> > 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/46OW5FQP...
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
I'd like the updated PEP to mention this approach and describe if/why it wasn't 
included
___
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/UMDSJGZZFUCO3LC6EPXU76ZTCRBYID57/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Jelle Zijlstra]

El mar, 10 ago 2021 a las 11:20, Thomas Grainger ()
escribió:

> Although the co_annoations code could intercept the NameError and replace
> return a ForwardRef object instead of the resolved name
>
I implemented a version of this in
https://github.com/larryhastings/co_annotations/pull/3 but Larry didn't
like it.


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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Thomas Grainger]

Although the co_annoations code could intercept the NameError and replace 
return a ForwardRef object instead of the resolved name
___
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/46OW5FQPHG54VIVKY2OQGLNITTPNCJXV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Damian Shaw]

> dataclasses need to check for ClassVar

Interesting, so the use case we are talking about is: 1) You are using
annotations to mean actual types, 2) But you also have to inspect them at
runtime, 3) For some of the types the name might not be defined at runtime
yet

In this example doesn't the current behavior, PEP 649, and PEP 563 (using
get_type_hints) all throw an exception?

Could PEP 649 be modified to say that if a NameError is raised the result
is not cached and therefore you can inspect it later at runtime to get the
real type once it is defined? Wouldn't that then allow users to write code
that allows for all use cases under this scenario?

- Damian (he/him)


On Tue, Aug 10, 2021 at 1:55 PM Thomas Grainger  wrote:

> dataclasses need to check for ClassVar
> ___
> 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/WOTCUBAO62WRRCCQAO6ZJNASSMK36MDW/
> 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/M3XEKV7KKAGG5QYR2XZSC35S7V4OALJS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Thomas Grainger]

Damian Shaw wrote:
> > dataclasses need to check for ClassVar
> > Interesting, so the use case we are talking about is: 1) You are using
> annotations to mean actual types, 2) But you also have to inspect them at
> runtime, 3) For some of the types the name might not be defined at runtime
> yet
> In this example doesn't the current behavior, PEP 649, and PEP 563 (using
> get_type_hints) all throw an exception?
> Could PEP 649 be modified to say that if a NameError is raised the result
> is not cached and therefore you can inspect it later at runtime to get the
> real type once it is defined? Wouldn't that then allow users to write code
> that allows for all use cases under this scenario?
> - Damian (he/him)
> On Tue, Aug 10, 2021 at 1:55 PM Thomas Grainger tagr...@gmail.com wrote:
> > dataclasses need to check for ClassVar
> > ___
> > 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/WOTCUBAO...
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
Yep it would need a note on the pep. It's a narrow usecase and everyone who 
does use the feature (attrs, pydantic etc) are watching this PEP carefully so 
it shouldn't be too much of a comparability concern
___
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/TVFMEVEUUQSDQLEN5COUVXLYDXMWFMXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Thomas Grainger]

dataclasses need to check for ClassVar
___
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/WOTCUBAO62WRRCCQAO6ZJNASSMK36MDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Carl Meyer]

On Mon, Aug 9, 2021 at 9:31 PM Inada Naoki  wrote:
> Currently, reference implementation of PEP 649 has been suspended.
> We need to revive it and measure performance/memory impact.

I volunteered to check performance impact in practice on the Instagram
codebase, which is almost fully annotated. However, when I tried, I
found that the reference implementation of PEP 649 wasn't even able to
import its own test file without a crash. I detailed the problem in
https://github.com/larryhastings/co_annotations/issues/12 a couple
months ago, but haven't gotten any response. Still willing to do this
testing on the IG codebase, but it seems like the implementation needs
some additional work before that will be possible.

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Damian Shaw]

> In this case PEP 649 doesn't help.

Sorry for the naive question but why doesn't PEP 649 help here? Is there
something fundamental about the dataclass that needs to inspect the type of
C.a to create the dataclass?

- Damian (he/him)

On Tue, Aug 10, 2021 at 1:10 PM Łukasz Langa  wrote:

>
> > On 10 Aug 2021, at 13:05, Eric V. Smith  wrote:
> >
> > If 649 is accepted, there will be few places where stringified
> annotations will be needed. For example, forward references that are
> defined before __annotations__ is examined will not need to be specified as
> strings. From the PEP: "Actually, annotations would become much easier to
> use, as they would now also handle forward references.
>
> In general, yes, agreed. However, a popular special case that you're
> intimately familiar with are class decorators. Since those are executed
> quite eagerly, you'll have to account for failing evaluation of forward
> references. Example:
>
> from dataclasses import dataclass
>
> @dataclass
> class C:
> a: A
>
> class A:
> ...
>
>
> In this case PEP 649 doesn't help. I don't see evaluation failures
> discussed explicitly in the PEP but I assume it would be a NameError. It
> would also be interesting to see if we can somehow make it handle
> annotations that refer to the class they're used in. Example:
>
> @dataclass
> class Node:
> parent: Node
>
> - Ł
> ___
> 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/FVJAUJ4TOYLAFJJS7UUPLFETXIBFBBEE/
> 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/6S5VOQQGEL74O7WCBAJECIZTQ5KNCTJD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Łukasz Langa]

> On 10 Aug 2021, at 13:05, Eric V. Smith  wrote:
> 
> If 649 is accepted, there will be few places where stringified annotations 
> will be needed. For example, forward references that are defined before 
> __annotations__ is examined will not need to be specified as strings. From 
> the PEP: "Actually, annotations would become much easier to use, as they 
> would now also handle forward references.

In general, yes, agreed. However, a popular special case that you're intimately 
familiar with are class decorators. Since those are executed quite eagerly, 
you'll have to account for failing evaluation of forward references. Example:

from dataclasses import dataclass

@dataclass
class C:
a: A

class A:
...


In this case PEP 649 doesn't help. I don't see evaluation failures discussed 
explicitly in the PEP but I assume it would be a NameError. It would also be 
interesting to see if we can somehow make it handle annotations that refer to 
the class they're used in. Example:

@dataclass
class Node:
parent: Node

- Ł


signature.asc
Description: Message signed with OpenPGP
___
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/FVJAUJ4TOYLAFJJS7UUPLFETXIBFBBEE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New __main__.rst

[Jack DeVries]

Huh, distributive pronouns... you learn something every day:

https://en.wikipedia.org/wiki/Distributive_pronoun

I think I'm just going to change the word "each" to "both", though,
because I don't like how "Each of these mechanisms is..." reads. Thank
you for the catch @MRAB.


On Tue, Aug 10, 2021 at 05:14:10PM +0100, MRAB wrote:
> On 2021-08-10 03:14, Jack DeVries wrote:
> > There have been a series of requests to enhance the current __main__.rst
> > document :
> > 
> > bpo-17359 
> > bpo-24632 
> > bpo-39452 
> > 
> > So, I rewrote it! I went ahead and hosted it on my website for you all to
> > easily take a look: 
> > https://jackdevries.com/pydoc__main__/library/__main__.html
> > 
> > Of course, you can go directly to the GitHub PR instead:
> > https://github.com/python/cpython/pull/26883
> > 
> > For reference, here is a link to the current document:
> > https://docs.python.org/3/library/__main__.html
> > 
> > This is a major change, so I'm thankful for anyone who can take the time to
> > review it. I am a new cpython contributor, so advice for how to push this 
> > ahead
> > is also welcome. For example, should I break this up into multiple PRs at 
> > this
> > point?
> > 
> Point of grammar: "Each of these mechanisms are related" should be "Each of
> these mechanisms is related". You might think that it's "are" because it
> follows "mechanisms", but it's "Each (something) is".
> ___
> 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/NRV2NHID465FGCMPHHLT7KS6WEOFSOU3/
> 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/WIRGGAYNSD2YTX3WQRZL6JO7E3UMH6N3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: New __main__.rst

[MRAB]

On 2021-08-10 03:14, Jack DeVries wrote:

There have been a series of requests to enhance the current __main__.rst
document :

bpo-17359 
bpo-24632 
bpo-39452 

So, I rewrote it! I went ahead and hosted it on my website for you all to
easily take a look: https://jackdevries.com/pydoc__main__/library/__main__.html

Of course, you can go directly to the GitHub PR instead:
https://github.com/python/cpython/pull/26883

For reference, here is a link to the current document:
https://docs.python.org/3/library/__main__.html

This is a major change, so I'm thankful for anyone who can take the time to
review it. I am a new cpython contributor, so advice for how to push this ahead
is also welcome. For example, should I break this up into multiple PRs at this
point?

Point of grammar: "Each of these mechanisms are related" should be "Each 
of these mechanisms is related". You might think that it's "are" because 
it follows "mechanisms", but it's "Each (something) is".

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Inada Naoki]

On Tue, Aug 10, 2021 at 5:11 PM Mark Shannon  wrote:
>
> >>
> >
> > Currently, reference implementation of PEP 649 has been suspended.
> > We need to revive it and measure performance/memory impact.
> >
> > As far as I remember, the reference implementation created a function
> > object for each methods.
>
> No function object is created under normal circumstances.
> __annotations__ is a property that calls the underlying
> __co_annotations__ property, which lazily creates a callable.
>
> I'll leave it to Larry to explain why __co_annotations__ isn't just a
> code object.
>

I am talking about methods.
As far as I remember, function objects are created for each method to
keep class namespace.
Larry explained it and possible optimization. That's what I am waiting for.
https://mail.python.org/archives/list/python-dev@python.org/message/2OOCEE6OMBQYEIJXEGFWIBE62VPIJHP5/

Regards,

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Eric V. Smith]

On 8/9/2021 11:25 PM, Inada Naoki wrote:

On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith  wrote:

Personally, I'd like to see PEP 649 accepted. There are a number of
issues on bpo where people expect dataclass's field.type to be an actual
Python object representing a type, and not a string. This field is
copied directly from __annotations__. If we stick with PEP 563's string
annotations, I'll probably just close these issues as "won't fix", and
tell the caller they need to convert the strings to Python objects
themselves. If 649 is accepted, then they'll all get their wish, and in
addition I can remove some ugly logic from dataclasses.


I don't think there is much difference.

PEP 563 is not default.
But the intent is/was to make it the default. That was the case in 3.10, 
up until right before the release of beta 1.

  And PEP 563 is not the only source of
stringified annotation.
So Accepting PEP 649 doesn't mean "they'll all get their wish". We
need to say "won't fix" anyway.


If 649 is accepted, there will be few places where stringified 
annotations will be needed. For example, forward references that are 
defined before __annotations__ is examined will not need to be specified 
as strings. From the PEP: "Actually, annotations would become much 
easier to use, as they would now also handle forward references.



Do we need to do anything here to move forward on this issue? I've
chatted with Larry and Mark Shannon, who have some additional thoughts
and I'm sure will chime in.


Currently, reference implementation of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.


Agreed.

--
Eric

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

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Mark Shannon]

On 10/08/2021 4:25 am, Inada Naoki wrote:

On Tue, Aug 10, 2021 at 12:30 AM Eric V. Smith  wrote:


Personally, I'd like to see PEP 649 accepted. There are a number of
issues on bpo where people expect dataclass's field.type to be an actual
Python object representing a type, and not a string. This field is
copied directly from __annotations__. If we stick with PEP 563's string
annotations, I'll probably just close these issues as "won't fix", and
tell the caller they need to convert the strings to Python objects
themselves. If 649 is accepted, then they'll all get their wish, and in
addition I can remove some ugly logic from dataclasses.



I don't think there is much difference.

PEP 563 is not default. And PEP 563 is not the only source of
stringified annotation.
So Accepting PEP 649 doesn't mean "they'll all get their wish". We
need to say "won't fix" anyway.



Do we need to do anything here to move forward on this issue? I've
chatted with Larry and Mark Shannon, who have some additional thoughts
and I'm sure will chime in.


My only comment concerned performance.

I won't claim that the cost of PEP 649 will be zero, but it won't be 
significantly more than PEP 563 if annotations are unused.
The cost of unmarshalling a code object will be greater than a string, 
but it won't be significant. Not only that, but we are actively looking 
to reduce startup in 3.11 which will reduce the overhead further.


If annotations *are* used, then PEP 649 should be cheaper as it relies 
on the interpreter to do the evaluation in an efficient fashion.
For users of dataclasses and Pydantic, I expect PEP 649 to outperform 
PEP 563.






Currently, reference implementation of PEP 649 has been suspended.
We need to revive it and measure performance/memory impact.

As far as I remember, the reference implementation created a function
object for each methods.


No function object is created under normal circumstances.
__annotations__ is a property that calls the underlying 
__co_annotations__ property, which lazily creates a callable.


I'll leave it to Larry to explain why __co_annotations__ isn't just a 
code object.



It means doubles function objects. It has major impact to memory
usage, startup time, and GC time.


Only if __annotations__ are widely used, in which case PEP 563 is 
probably worse.


Cheers,
Mark.



There was an idea to avoid creating function objects for most cases.
But it was not implemented.

Regards,


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