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

I will try to find time to review the code. On Thu, Aug 12, 2021 at 08:56 Larry Hastings wrote: > > On 8/12/21 8:25 AM, Guido van Rossum wrote: > > Maybe we could specialize the heck out of this and not bother with a > function object? In the end we want to execute the code, the function > objec

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

On 8/12/21 8:25 AM, Guido van Rossum wrote: Maybe we could specialize the heck out of this and not bother with a function object? In the end we want to execute the code, the function object is just a convenient way to bundle defaults, free variables (cells) and globals. But co_annotation has n

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

Maybe we could specialize the heck out of this and not bother with a function object? In the end we want to execute the code, the function object is just a convenient way to bundle defaults, free variables (cells) and globals. But co_annotation has no arguments or defaults, and is only called once.

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

Lazy loading code object solves only a half of the problem. I am worrying about function objects for annotation too. Function objects are heavier than code objects. And they are GC-tracked objects. I want to know how we can reduce the function objects created for annotation in PEP 649, before dep

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

On Thu, Aug 12, 2021 at 3:01 AM Larry Hastings wrote: > > On 8/11/21 5:15 AM, Chris Angelico wrote: > > On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: > > This approach shouldn't break reasonable existing code. That said, this > change would be observable from Python, and pathological c

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

On Wed, Aug 11, 2021 at 2:13 PM Barry Warsaw wrote: > As for the second question, it means that we have to be very careful that the > folks who use type annotation at compile/static checking time (e.g. mypy and > friends) explicitly consider the existing use cases and needs of the runtime > typ

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

On 8/11/2021 11:07 AM, Jukka Lehtosalo wrote: On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger > wrote: Would: ``` @dataclass class Node:     global_node: __class__ | None ``` "Just work" with co_annotations? This feels too specialized to m

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

On Aug 9, 2021, at 08:27, Eric V. Smith wrote: > > 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

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

I don't think I've seen code like this. It would be incredibly useful to have a cpython-primer (like mypy-primer and black-primer) that ran as many test suites as possible from pypi with every cPython commit ___ Python-Dev mailing list -- python-dev@pyt

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

On 8/11/21 5:15 AM, Chris Angelico wrote: On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: This approach shouldn't break reasonable existing code. That said, this change would be observable from Python, and pathological code could notice and break. For example: def ensure_Foo_is_a_cl

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

On 8/11/2021 7:56 AM, Larry Hastings wrote: So, here's an idea, credit goes to Eric V. Smith.  What if we tweak how decorators work, /jst slghtly/, so that they work like the workaround code above? Specifically: currently, decorators are called just after the function or class object

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

On Wed, Aug 11, 2021 at 7:09 AM Larry Hastings wrote: > 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 P

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

On Wed, Aug 11, 2021 at 2:27 PM Guido van Rossum wrote: > As it happens, I have a working prototype of lazy in marshaling that would > work well for this. > > Nice to see you keep the time machine in working order ... Kind regards, Steve ___ Python-Dev

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

On Wed, Aug 11, 2021 at 2:56 PM Thomas Grainger wrote: > Would: > ``` > @dataclass > class Node: > global_node: __class__ | None > ``` > > "Just work" with co_annotations? > This feels too specialized to me. It would be great to also handle forward references to other classes and cyclic ref

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

Would: ``` @dataclass class Node: global_node: __class__ | None ``` "Just work" with co_annotations? ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lis

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

Oh, I agree it shouldn’t reference the typing module. But it should not raise NameError. This whole thing already is a special case. We can debate what else it should, e.g. skip the name, return a fixed error token, return an error token that includes the name that failed (this is part if the NameE

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

As it happens, I have a working prototype of lazy in marshaling that would work well for this. On Wed, Aug 11, 2021 at 06:07 Larry Hastings wrote: > On 8/11/21 5:21 AM, Inada Naoki wrote: > > But memory footprint and GC time is still an issue. > Annotations in PEP 649 semantics can be much heavi

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

Larry Hastings wrote: > On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: > > On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger > mailto:tagr...@gmail.com> wrote: > > Larry Hastings wrote: > > > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > > > I think as long as there's a test case for something like >

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

On 8/11/21 5:21 AM, Inada Naoki wrote: But memory footprint and GC time is still an issue. Annotations in PEP 649 semantics can be much heavier than docstrings. I'm convinced that, if we accept PEP 649 (or something like it), we can reduce its CPU and memory consumption. Here's a slightly c

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

> 2021/08/11 19:22、Paul Moore のメール: > > Also, I don't think that improving performance is a > justification for a non-trivial backward compatibility break (I don't > recall a case where we've taken that view in the past) so "PEP 649 > solves forward references without a backward compatibility imp

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

On Wed, Aug 11, 2021 at 10:03 PM Larry Hastings wrote: > Specifically: currently, decorators are called just after the function or > class object is created, before it's bound to a variable. But we could > change it so that we first bind the variable to the initial value, then call > the decor

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

On 8/11/21 2:48 AM, Jukka Lehtosalo wrote: On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger > wrote: Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something like > > @dataclass > >

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

On Wed, 11 Aug 2021 at 07:37, Larry Hastings wrote: > [...] > 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. I think this is a very important point. As originally implemented, annotations allow

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

On Wed, Aug 11, 2021 at 10:32 AM Thomas Grainger wrote: > Larry Hastings wrote: > > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > > I think as long as there's a test case for something like > > > @dataclass > > > class Node: > > > global_node: ClassVar[Node | None] > > > left: InitVar

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

Larry Hastings wrote: > On 8/11/21 12:02 AM, Thomas Grainger wrote: > > I think as long as there's a test case for something like > > @dataclass > > class Node: > > global_node: ClassVar[Node | None] > > left: InitVar[Node | None] > > right: InitVar[None | None] > > > > the bug http

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

On 8/11/21 12:02 AM, Thomas Grainger wrote: I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the curren

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

I think as long as there's a test case for something like ``` @dataclass class Node: global_node: ClassVar[Node | None] left: InitVar[Node | None] right: InitVar[None | None] ``` the bug https://bugs.python.org/issue33453 and the current implementation https://github.com/python/cpyth

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

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 typi

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

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/m

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

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 rule

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

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 u

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

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 th

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

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.

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

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

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

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://mai

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

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

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

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

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

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.

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

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

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

> 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

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

> 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: "Ac

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

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 me

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

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 f

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

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

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

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 __ann

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

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

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

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 56

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Sun, 18 Apr 2021, 1:59 am Jelle Zijlstra, wrote: > El sáb, 17 abr 2021 a las 8:30, Nick Coghlan () > escribió:. > >> >> Metaclass __prepare__ methods can inject names into the class namespace >> that the compiler doesn't know about, so yeah, it unfortunately has to be >> conservative and use L

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

El sáb, 17 abr 2021 a las 8:30, Nick Coghlan () escribió: > > > On Fri, 16 Apr 2021, 3:14 pm Larry Hastings, wrote: > >> >> Anyway I assume it wasn't "fixable". The compiler would presumably >> already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL >> would be cheaper every tim

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Fri, 16 Apr 2021, 3:14 pm Larry Hastings, wrote: > > Anyway I assume it wasn't "fixable". The compiler would presumably > already prefer to generate LOAD_GLOBAL vs LOAD_NAME, because LOAD_GLOBAL > would be cheaper every time for a global or builtin. The fact that it > already doesn't do so i

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/15/21 9:24 PM, Inada Naoki wrote: Unlike simple function case, PEP 649 creates function object instead of code object for __co_annotation__ of methods. It cause this overhead. Can we avoid creating functions for each annotation? As the implementation of PEP 649 currently stands, there a

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

> > I will read PEP 649 implementation to find missing optimizations other > than GH-25419 and GH-23056. > I found each "__co_annotation__" has own name like "func0.__co_annotation__". It increased pyc size a little. I created a draft pull request for cherry-picking GH-25419 and GH-23056 and using

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/15/21 2:02 PM, Sebastián Ramírez wrote: ## Questions I'm not very familiar with the internals of Python, and I'm not sure how the new syntax for `Union`s using the vertical bar character ("pipe", "|") work. But would PEP 649 still support things like this?: def run(arg: int | str = 0): p

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Thanks Brett Cannon for suggesting to get Samuel Colvin (Pydantic) and me, Sebastián Ramírez (FastAPI and Typer) involved in this. TL;DR: it seems to me PEP 649 would be incredibly important/useful for Pydantic, FastAPI, Typer, and similar tools, and their communities. ## About FastAPI, Pydanti

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

I updated the benchmark little: * Added no annotation mode for baseline performance. * Better stats output. https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d ``` # No annotation (master + GH-25419) $ ./python ~/ann_test.py 0 code size: 102967 bytes memory: 181288 bytes unmarshal:

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Thu, Apr 15, 2021 at 11:09 AM Larry Hastings wrote: > > Thanks for doing this! I don't think PEP 649 is going to be accepted or > rejected based on either performance or memory usage, but it's nice to see > you confirmed that its performance and memory impact is acceptable. > > > If I run "a

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Thanks for doing this!  I don't think PEP 649 is going to be accepted or rejected based on either performance or memory usage, but it's nice to see you confirmed that its performance and memory impact is acceptable. If I run "ann_test.py 1", the annotations are already turned into strings.

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

I added memory usage data by tracemalloc. ``` # Python 3.9 w/ old semantics $ python3 ann_test.py 1 code size: 121011 memory: (385200, 385200) unmarshal: avg: 0.3341682574478909 +/- 3.700437551781949e-05 exec: avg: 0.4067857594229281 +/- 0.0006858555167675445 # Python 3.9 w/ PEP 563 semantics $ p

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

I created simple benchmark: https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d This benchmark creates 1000 annotated functions and measure time to load and exec. And here is the result. All interpreters are built without --pydebug, --enable-optimization, and --with-lto. ``` # Python

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Larry Hastings wrote: > On 4/14/21 1:42 PM, Baptiste Carvello wrote: > > Are there specific annoyances associated with quoting always, apart > > from the 2 more characters? > Yes.  Since the quoted strings aren't parsed by Python, syntax errors in > these strings go undetected until somebody doe

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Baptiste Carvello wrote: > Le 14/04/2021 à 19:44, Guido van Rossum a écrit : > > No, what I heard is that, since in *most* cases the string quotes are > > not needed, people are surprised and annoyed when they encounter cases > > where they are needed. > Well, I had assumed quotes would be used i

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/14/21 1:42 PM, Baptiste Carvello wrote: Are there specific annoyances associated with quoting always, apart from the 2 more characters? Yes.  Since the quoted strings aren't parsed by Python, syntax errors in these strings go undetected until somebody does parse them (e.g. your static t

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, 2021-04-14 at 22:42 +0200, Baptiste Carvello wrote: > That's assuming the syntax in the annotations doesn't diverge too > much > from the Python syntax as far as brackets etc are concerned. I must > say > I'm not too worried about typing. But the hypothetic "def foo(prec: > --precision int

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi, Le 14/04/2021 à 19:44, Guido van Rossum a écrit : > > No, what I heard is that, since in *most* cases the string quotes are > not needed, people are surprised and annoyed when they encounter cases > where they are needed. And if you have a large code base it takes an > expensive run of the st

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi Larry, On 4/14/21, 1:56 PM, "Larry Hastings" wrote: >My plan was to post it here and see what the response was first. Back in > January, when I posted the first draft, I got some very useful feedback that > resulted in some dramatic changes. This time around, so far, nobody has > su

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

My plan was to post it here and see what the response was first. Back in January, when I posted the first draft, I got some very useful feedback that resulted in some dramatic changes.  This time around, so far, nobody has suggested even minor changes.  Folks have just expressed their opinion

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 12:08 PM Guido van Rossum wrote: > Let's just wait for the SC to join the discussion. I'm sure they will, > eventually. > FYI the PEP has not been sent to us via https://github.com/python/steering-council/issues as ready for pronouncement, so we have not started officiall

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Let's just wait for the SC to join the discussion. I'm sure they will, eventually. On Wed, Apr 14, 2021 at 11:12 AM Larry Hastings wrote: > On 4/14/21 10:44 AM, Guido van Rossum wrote: > > besides the cost of closing the door to relaxed annotation syntax, there's > the engineering work of undoin

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 11:03 AM Paul Bryan wrote: > What would you expect get_type_hints(...) to return with relaxed syntax? > Today, for type hint annotations, it returns a type, which I'd argue is an > important feature to preserve (in it or some successor). > It would have to return some oth

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/14/21 10:44 AM, Guido van Rossum wrote: besides the cost of closing the door to relaxed annotation syntax, there's the engineering work of undoing the work that was done to make `from __future__ import annotations` the default (doing this was a significant effort spread over many commits,

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

What would you expect get_type_hints(...) to return with relaxed syntax? Today, for type hint annotations, it returns a type, which I'd argue is an important feature to preserve (in it or some successor). On Wed, 2021-04-14 at 10:54 -0700, Guido van Rossum wrote: > On Wed, Apr 14, 2021 at 10:47 AM

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 10:47 AM Paul Bryan wrote: > I favour annotations for type hints; the writing's been on the wall for > some time. I think the necessary escape hatch for those using it for other > purposes should be Annotated[Any, ...] (or a similar, nicer alternative). > > Guido, one of t

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

I favour annotations for type hints; the writing's been on the wall for some time. I think the necessary escape hatch for those using it for other purposes should be Annotated[Any, ...] (or a similar, nicer alternative). Guido, one of the difficulties I'm having is understanding the direction you'

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 9:42 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Hi, > > tl;dr: imho the like or dislike of PEP 563 is related to whether people > intend to learn a second syntax for typing, or would rather ignore it; > both groups should be taken into account. > > Le

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 6:58 PM Inada Naoki wrote: > On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings > wrote: > > > > > > On 4/13/21 1:52 PM, Guido van Rossum wrote: > > > > > > Because typing is, to many folks, a Really Important Concept, and it's > confusing to use the same syntax ("x: blah bl

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 6:48 PM Larry Hastings wrote: > > On 4/13/21 1:52 PM, Guido van Rossum wrote: > > On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings > wrote: > >> >> On 4/12/21 7:24 PM, Guido van Rossum wrote: >> >> I've been thinking about this a bit, and I think that the way forward is >>

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi, tl;dr: imho the like or dislike of PEP 563 is related to whether people intend to learn a second syntax for typing, or would rather ignore it; both groups should be taken into account. Le 13/04/2021 à 19:30, Guido van Rossum a écrit : > On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello >

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: To be honest, the most pressing issue with annotations is the clumsy way that type variables have to be introduced. The current convention, `T = TypeVar('T')`, is both verbose (why do I have to repeat the name?) and widely misunderstood (many help re

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

It looks like a small subset of PEP 484, syntactically. So it should be fine. Possibly cython might be interested in using a relaxed notation if it is ever introduced, e.g. ‘long long’ or ‘static int’ (for a return type)? On Wed, Apr 14, 2021 at 02:27 Antoine Pitrou wrote: > > For the record, Cy

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

For the record, Cython allows using annotations for typing: https://cython.readthedocs.io/en/latest/src/tutorial/pure.html#pep-484-type-annotations I don't know if they are fully compatible with the type hints we're talking about here. Regards Antoine. On Wed, 14 Apr 2021 10:58:07 +0900 Inad

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Wed, Apr 14, 2021 at 10:44 AM Larry Hastings wrote: > > > On 4/13/21 1:52 PM, Guido van Rossum wrote: > > > Because typing is, to many folks, a Really Important Concept, and it's > confusing to use the same syntax ("x: blah blah") for different purposes, in > a way that makes it hard to tell

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 1:52 PM, Guido van Rossum wrote: On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings > wrote: On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of ann

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/21 3:28 PM, Terry Reedy wrote: On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + codeop modules i

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/13/2021 4:21 AM, Baptiste Carvello wrote: Le 12/04/2021 à 03:55, Larry Hastings a écrit : * in section "Interactive REPL Shell": For the sake of simplicity, in this case we forego delayed evaluation. The intention of the code + codeop modules is that people should be able to write in

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 12:32 PM Larry Hastings wrote: > > On 4/12/21 7:24 PM, Guido van Rossum wrote: > > I've been thinking about this a bit, and I think that the way forward is > for Python to ignore the text of annotations ("relaxed annotation syntax"), > not to try and make it available as a

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 7:24 PM, Guido van Rossum wrote: I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression. To be honest, the most pressing issue with annota

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 9:39 AM Baptiste Carvello < devel2...@baptiste-carvello.net> wrote: > Le 13/04/2021 à 04:24, Guido van Rossum a écrit : > > I've been thinking about this a bit, and I think that the way forward is > > for Python to ignore the text of annotations ("relaxed annotation > > syn

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi Larry, On 4/12/21, 6:57 PM, "Larry Hastings" wrote: Again, by "works on PEP 563 semantics", you mean "doesn't raise an error". But the code has an error. It's just that it has been hidden by PEP 563 semantics. I don't agree that changing Python to automatically hide errors is an

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi, Le 12/04/2021 à 03:55, Larry Hastings a écrit : > > I look forward to your comments, 2 reading notes: * in section "Annotations That Refer To Class Variables": > If it's possible that an annotation function refers > to class variables--if all these conditions are true: > > * The annotation

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

Hi, Le 13/04/2021 à 04:24, Guido van Rossum a écrit : > I've been thinking about this a bit, and I think that the way forward is > for Python to ignore the text of annotations ("relaxed annotation > syntax"), not to try and make it available as an expression. Then, what's wrong with quoting? It's

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Mon, 2021-04-12 at 19:52 -0700, Guido van Rossum wrote: > Why not submit a PR that adds caching to get_type_hints(), rather > than promote a paradigm shift? A couple of reasons: 1. In reviewing the code, I didn't find an obvious way to store cached values. Anything but a non-trivial change w

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Mon, Apr 12, 2021 at 7:47 PM Paul Bryan wrote: > In 3.9 this cost is paid once when a type is defined. However, in 3.10, it > gets expensive, because when the string is evaluated by get_type_hints, its > result is not stored/cached anywhere (repeated calls to get_type_hints > results in repeat

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, 2021-04-13 at 11:33 +0900, Inada Naoki wrote: > On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote: > > > > On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote: > > > > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings > > wrote: > > > > > > This is really the heart of the debate over PE

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 11:18 AM Paul Bryan wrote: > > On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote: > > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote: > > > This is really the heart of the debate over PEP 649 vs PEP 563. If you > examine an annotation, and it references an undef

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

I've been thinking about this a bit, and I think that the way forward is for Python to ignore the text of annotations ("relaxed annotation syntax"), not to try and make it available as an expression. To be honest, the most pressing issue with annotations is the clumsy way that type variables have

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, 2021-04-13 at 10:47 +0900, Inada Naoki wrote: > On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings > wrote: > > This is really the heart of the debate over PEP 649 vs PEP 563.  If > > you examine an annotation, and it references an undefined symbol, > > should that throw an error?  There is

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 9:57 AM Larry Hastings wrote: > > > On 4/12/21 4:50 PM, Inada Naoki wrote: > > PEP 563 solves all problems relating to types not accessible in runtime. > There are many reasons users can not get types used in annotations at runtime: > > * To avoid circular import > * Types

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 4:50 PM, Inada Naoki wrote: PEP 563 solves all problems relating to types not accessible in runtime. There are many reasons users can not get types used in annotations at runtime: * To avoid circular import * Types defined only in pyi files * Optional dependency that is slow to impor

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On Tue, Apr 13, 2021 at 8:58 AM Larry Hastings wrote: > > On 4/12/21 4:50 PM, Inada Naoki wrote: > > As PEP 597 says, eval() is slow. But it can avoidable in many cases > with PEP 563 semantics. > > PEP 597 is "Add optional EncodingWarning". You said PEP 597 in one other > place too. Did you me

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations Using Descriptors, round 2

On 4/12/21 4:50 PM, Inada Naoki wrote: As PEP 597 says, eval() is slow. But it can avoidable in many cases with PEP 563 semantics. PEP 597 is "Add optional EncodingWarning".  You said PEP 597 in one other place too.  Did you mean PEP 649 in both places? Cheers, //arry/ __

  1   2   >