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

[Inada Naoki]

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

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.
It means doubles function objects. It has major impact to memory
usage, startup time, and GC time.

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

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

[Python-Dev] New __main__.rst

[Jack DeVries]

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?

Thank you all!
___
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/BSAS3N73T5ILYCQQ6JQBGHL5RPFHNOPL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Brett Cannon]

On Mon, Aug 9, 2021 at 8:31 AM Eric V. Smith  wrote:

> I'd like to revive the discussion of PEP 649
> [https://www.python.org/dev/peps/pep-0649/] that started shortly before
> development of 3.10 features was closed. This is Larry's PEP to defer
> evaluation of __annotations__ until it's actually accessed. During the
> discussion the decision was made to back out the change that made "from
> __future__ import annotations" (PEP 563
> [https://www.python.org/dev/peps/pep-0563/]) the default behavior for
> 3.10.
>
> My understanding is that PEP 649 is currently in front of the SC.


Correct.


> But do
> we need to have any additional discussion here?


I think it's worth discussing whether PEP 649 is the solution we want to
see as the solution to this problem or not?


> My recollection is that
> we backed out the PEP 563 change because we didn't feel we had enough
> time to come to a good decision one way or the other before 3.10.
>

Correct.


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

I think the question is whether we have general consensus around PEP 649?

-Brett


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

[Python-Dev] Re: Windows buildbots may be broken

[Tim Peters]

Sorry, all! This post was pure spam - I clicked the wrong button on
the moderator UI. The list has already been set to auto-reject any
future posts from this member.

On Mon, Aug 9, 2021 at 10:51 AM ridhimaortiz--- via Python-Dev
 wrote:
>
> It is really nice post. https://bit.ly/3fsxwwl
> ___
> 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/WMJOVXKRH2ILPADU5QMLIVEIXHWPBOLZ/
> 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/INKI3S6ZZTQDVXZ3Y5BIJJO6QMGQJ5EK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Windows buildbots may be broken

[ridhimaortiz--- via Python-Dev]

It is really nice post. https://bit.ly/3fsxwwl
___
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/WMJOVXKRH2ILPADU5QMLIVEIXHWPBOLZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 646 (Variadic Generics): final call for comments

[Dan Moldovan via Python-Dev]

I'd be interested in using this the mechanisms defined in this PEP to define 
rank-generic Tensor types in TensorFlow, which are important in specifying 
`tf.function` signatures in a Pythonic way, using type annotations (rather than 
the custom `input_signature` mechanism we have today - see this issue: 
https://github.com/tensorflow/tensorflow/issues/31579). Variadic generics are 
among the last few missing pieces to create an elegant set of type definitions 
for tensors and shapes.

Best,

Dan Moldovan
Senior Software Engineer, TensorFlow Dev Team
___
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/HTCARTYYCHETAMHB6OVRNR5EW5T2CP4J/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Eric V. Smith]

Some prior discussions:

"PEP 563 in light of PEP 649": 
https://mail.python.org/archives/list/python-dev@python.org/message/ZBJ7MD6CSGM6LZAOTET7GXAVBZB7O77O/


"In support of PEP 649": 
https://mail.python.org/archives/list/python-dev@python.org/message/7VMJWFGHVXDSRQFHMXVJKDDOVT47B54T/


"PEP 563 and 649: The Great Compromise": 
https://mail.python.org/archives/list/python-dev@python.org/message/WUZGTGE43T7XV3EUGT6AN2N52OD3U7AE/


I'm sure there are other threads I missed.

--
Eric

On 8/9/2021 11:27 AM, Eric V. Smith wrote:
I'd like to revive the discussion of PEP 649 
[https://www.python.org/dev/peps/pep-0649/] that started shortly 
before development of 3.10 features was closed. This is Larry's PEP to 
defer evaluation of __annotations__ until it's actually accessed. 
During the discussion the decision was made to back out the change 
that made "from __future__ import annotations" (PEP 563 
[https://www.python.org/dev/peps/pep-0563/]) the default behavior for 
3.10.


My understanding is that PEP 649 is currently in front of the SC. But 
do we need to have any additional discussion here? My recollection is 
that we backed out the PEP 563 change because we didn't feel we had 
enough time to come to a good decision one way or the other before 3.10.


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.


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.



--
Eric V. Smith

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

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

[Eric V. Smith]

I'd like to revive the discussion of PEP 649 
[https://www.python.org/dev/peps/pep-0649/] that started shortly before 
development of 3.10 features was closed. This is Larry's PEP to defer 
evaluation of __annotations__ until it's actually accessed. During the 
discussion the decision was made to back out the change that made "from 
__future__ import annotations" (PEP 563 
[https://www.python.org/dev/peps/pep-0563/]) the default behavior for 3.10.


My understanding is that PEP 649 is currently in front of the SC. But do 
we need to have any additional discussion here? My recollection is that 
we backed out the PEP 563 change because we didn't feel we had enough 
time to come to a good decision one way or the other before 3.10.


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.


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.


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