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

I certainly wouldn't want to keep `from __future__ import annotations` in the language forever if Larry's PEP is accepted. Of course you can still use explicit string literals in annotations. Your observation about the @dataclass decorator is significant. Thanks for that. On Tue, Feb 16, 2021

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

PEP 649 doesn't prevent to use stringified annotations (Larry has previously mentioned it in its response to Paul Bryan), and they seem to be still required when `if TYPE_CHECKING:` is used, despite the PEP claim. And my last message bring some use cases where strings are also required

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

If I've understood the PEP correctly, it would cause the following simple example to fail: ```python from dataclasses import dataclass @dataclass class User: name: str friends: list[User] ``` In fact, when the `dataclass` decorator is called, `User` class is not yet added to the module

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

It is an issue if you use `__annotations__` directly and you are using PEP 563's `from __future__ import annotations`. This currently gives some strings that may or may not refer to existing globals. With Larry's PEP 649 it will raise an error. On Tue, Feb 16, 2021 at 9:35 AM Joseph Perez wrote:

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

> Please note that this is a thread about PEP 649. > > If PEP 649 accepted and PEP 563 dies, all such idioms breaks annotation completely. > > Users need to import all heavy modules and circular references used only type hints, or user can not get even string form annotation which is very useful

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

I don't work on these sorts of codebases, and I don't use type hints or static type checking.  So I'm not really qualified to judge how bad / widespread a problem this is.  It's my hope that the greater Python core dev / user community can ascertain how serious this is. My main observation

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

On Sun, Feb 14, 2021 at 7:17 PM Inada Naoki wrote: > On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez wrote: > > > > > How about having a pseudo-module called __typing__ that is > > > ignored by the compiler: > > > > > > from __typing__ import ... > > > > > > would be compiled to a no-op, but

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

On Mon, Feb 15, 2021 at 10:20 AM Joseph Perez wrote: > > > How about having a pseudo-module called __typing__ that is > > ignored by the compiler: > > > > from __typing__ import ... > > > > would be compiled to a no-op, but recognised by type checkers. > > If you want to do run-time typing stuff,

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

By the way, without adding an other constant, `__debug__` can also be used. It discards runtime overhead when it matters, in optimized mode. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

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

> How about having a pseudo-module called __typing__ that is > ignored by the compiler: > > from __typing__ import ... > > would be compiled to a no-op, but recognised by type checkers. If you want to do run-time typing stuff, you would use There is already a way of doing that: `if

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

On Mon, 18 Jan 2021 15:54:32 -0800 Larry Hastings wrote: > On 1/18/21 3:42 PM, Inada Naoki wrote: > > Many type hinting use cases don't need type objects in runtime. > > So I think PEP 563 is better for type hinting user experience. > > You mean, in situations where the user doesn't want to

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

Hello, On Tue, 19 Jan 2021 14:31:49 +1300 Greg Ewing wrote: > On 19/01/21 1:13 pm, Inada Naoki wrote: > > I don't want to import modules used only in type hints. I don't want > > to import even "typing". > > How about having a pseudo-module called __typing__ that is > ignored by the

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

On 19/01/21 1:13 pm, Inada Naoki wrote: I don't want to import modules used only in type hints. I don't want to import even "typing". How about having a pseudo-module called __typing__ that is ignored by the compiler: from __typing__ import ... would be compiled to a no-op, but recognised by

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

On Tue, Jan 19, 2021 at 8:54 AM Larry Hastings wrote: > > On 1/18/21 3:42 PM, Inada Naoki wrote: > > Many type hinting use cases don't need type objects in runtime. > So I think PEP 563 is better for type hinting user experience. > > You mean, in situations where the user doesn't want to import

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

On 1/18/21 3:42 PM, Inada Naoki wrote: Many type hinting use cases don't need type objects in runtime. So I think PEP 563 is better for type hinting user experience. You mean, in situations where the user doesn't want to import the types, because of heavyweight imports or circular imports? 

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

On Tue, Jan 19, 2021 at 6:02 AM Larry Hastings wrote: > > > Oh, okay. I haven't used the static type checkers, so it's not clear to me > what powers they do and don't have. It was only a minor suggestion anyway. > Perhaps PEP 649 will be slightly inconvenient to people exploring their code

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

On 1/18/21 12:24 PM, Guido van Rossum wrote: On Sun, Jan 17, 2021 at 7:33 AM Larry Hastings > wrote: If your imports are complicated, you could always hide them in a function.  I just tried this and it seems to work fine: def my_imports():    

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

On Sun, Jan 17, 2021 at 7:33 AM Larry Hastings wrote: > If your imports are complicated, you could always hide them in a > function. I just tried this and it seems to work fine: > > def my_imports(): > global other_mod > import other_mod > > So, you could put all your imports in such a

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

If you never examine __annotations__, then you can refer to symbols that are never defined and nothing bad happens.  It's just like writing a function that refers to undefined symbols, then never calling that function. If you examine __annotations__, and the annotations refer to values that

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

This PEP doesn't cover about what happened when __co_annotation__() failed (e.g. NameError). Forward reference is a major reason, but not a only reason for using string annotation. There are two other reasons: * Avoid importing heavy module. * Avoid circular imports. In these cases, this

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

Given your comments below, I'd summarize the semantics you want as: Looking up names for annotations should work exactly as it does today with "stock" semantics, except annotations should also see names that haven't been declared yet. Thus an annotation should be able to see names set

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

On Fri, Jan 15, 2021 at 18:15 Greg Ewing wrote: > On 16/01/21 2:09 pm, Guido van Rossum wrote: > > Yeah, that wasn't very clear, and I'm not 100% sure I got it right. But > > consider this: > > ``` > > class Outer: > > foo = 1 > > class Inner: > > print(foo) > > That's true.

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

On 16/01/21 2:09 pm, Guido van Rossum wrote: Yeah, that wasn't very clear, and I'm not 100% sure I got it right. But consider this: ``` class Outer:     foo = 1     class Inner:     print(foo) That's true. So maybe the user should have to be explicit in cases like this: class Outer:

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

On Fri, Jan 15, 2021 at 4:45 PM Greg Ewing wrote: > On 16/01/21 9:38 am, Guido van Rossum wrote: > > On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings > > wrote: > > > > class OuterCls: > > class InnerCls: > > def

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

On 16/01/21 9:38 am, Guido van Rossum wrote: On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings > wrote: class OuterCls:     class InnerCls:         def method(a:OuterCls.InnerCls=None): pass We've turned the local reference into a global

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

On 1/15/21 3:29 PM, Greg Ewing wrote: On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide

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

Would annotations() just access the dunder, like other builtins (and then result in the descriptor resolving __co_annotations__ as proposed), or would calling it be required to actually resolve __co_annotations__? I think it should probably be the former. On Sat, 2021-01-16 at 12:29 +1300, Greg

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

On 16/01/21 7:56 am, Larry Hastings wrote: As mentioned previously in this thread, typing.get_type_hints() is opinionated in ways that users of annotations may not want. This brings us back to my idea of introducing a new annotations() function to hide the details. It wouldn't be the same

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

I knew I was missing something. Agree, annotations are not necessarily type hints. On Fri, 2021-01-15 at 10:56 -0800, Larry Hastings wrote: > > On 1/15/21 10:12 AM, Paul Bryan wrote: > > > I wonder if then the __co_annotations__ call and overwriting of > > __annotations__ should be explicitly

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

On Fri, Jan 15, 2021 at 10:53 AM Larry Hastings wrote: > > Sorry it took me 3+ days to reply--I had a lot to think about here. But I > have good things to report! > > > On 1/11/21 8:42 PM, Guido van Rossum wrote: > > On Mon, Jan 11, 2021 at 1:20 PM Larry Hastings wrote: > >> PEP 563 states: >>

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

On 1/15/21 10:12 AM, Paul Bryan wrote: I wonder if then the __co_annotations__ call and overwriting of __annotations__ should be explicitly caused by a to get_type_hints instead of (mysteriously) occurring on an attempt to getattr __annotations__. I would say: absolutely not.  While all

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

Sorry it took me 3+ days to reply--I had a lot to think about here.  But I have good things to report! On 1/11/21 8:42 PM, Guido van Rossum wrote: On Mon, Jan 11, 2021 at 1:20 PM Larry Hastings > wrote: PEP 563 states: For code that uses type hints,

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

OK. Makes sense to think of __annotations__ as being the location of the final, stable, "affixed" type hints. I wonder if then the __co_annotations__ call and overwriting of __annotations__ should be explicitly caused by a to get_type_hints instead of (mysteriously) occurring on an attempt to

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

On 1/11/21 6:34 PM, Paul Bryan wrote: On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote: On 1/11/21 5:02 PM, Paul Bryan wrote: I'm probably naive, but is there a reason that one could not just store a callable in __annotations__, and use the descriptor to resolve it to a dictionary

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

Hello, On Wed, 13 Jan 2021 05:04:36 - "Jim J. Jewett" wrote: > Paul Sokolovsky wrote: > > Ok, let's take "module attribute" as an example. Why do you think > > there's anything wrong with this code: > > == > > import config > > from .types import * > > if config.SUPPORT_BIGINT: > >

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

Paul Sokolovsky wrote: > Ok, let's take "module attribute" as an example. Why do you think > there's anything wrong with this code: > == > import config > from .types import * > if config.SUPPORT_BIGINT: > var: bigint = 1 > else: > var: int64 = 1 "Wrong" is too strong, but it would be

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

On Wed, Jan 13, 2021 at 1:47 AM Larry Hastings wrote: > > On 1/11/21 5:33 PM, Inada Naoki wrote: > > Note that PEP 563 semantics allows more efficient implementation. > Annotation is just a single constant tuple, not a dict. > We already have the efficient implementation for Python 3.10. > > The

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

On 1/12/21 3:53 PM, Greg Ewing wrote: On 13/01/21 5:47 am, Larry Hastings wrote: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code object at runtime--bytecode, lnotab, names,

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

On 13/01/21 5:47 am, Larry Hastings wrote: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code object at runtime--bytecode, lnotab, names, consts, etc. Would that tuple be

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

On 13/01/21 6:54 am, Larry Hastings wrote: Note that this only works in the current version of the PEP / prototype, where annotations are strictly evaluated in module scope.  If we start supporting closures, those need "cell" objects, which IIUC can't be marshalled. The cells belong to the

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

On Tue, Jan 12, 2021 at 11:31 AM Jim J. Jewett wrote: > Larry Hastings wrote: > > The control-flow exclusion is for /module//attribute/ or /class > > attribute/ annotations: > > class C: > >if random.random() > 0.5: > > my_attr:int=3 > >else: > > my_attr2:float=3.5 > > That

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

On 1/12/21 12:16 PM, Paul Bryan wrote: On Tue, 2021-01-12 at 09:54 -0800, Larry Hastings wrote: Note that this only works in the current version of the PEP / prototype, where annotations are strictly evaluated in module scope.  If we start supporting closures, those need "cell" objects,

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

Hello, On Mon, 11 Jan 2021 13:44:45 -0800 Larry Hastings wrote: > The control-flow exclusion is for /module//attribute/ or /class > attribute/ annotations: > > class C: >   if random.random() > 0.5: >     my_attr:int=3 >   else: >     my_attr2:float=3.5 Ok, let's take

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

On Tue, 2021-01-12 at 09:54 -0800, Larry Hastings wrote: > Note that this only works in the current version of the PEP / > prototype, where annotations are strictly evaluated in module scope.  > If we start supporting closures, those need "cell" objects, which > IIUC can't be marshalled. Since the

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

On 1/12/21 11:26 AM, Jim J. Jewett wrote: If I understand correctly, the problem is that you can't store multiple alternative annotations on my_attr. Therefore: class C: my_attr:(int if random.random > 0.5 else float) should be OK, because there is only a single annotation.

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

Larry Hastings wrote: > The control-flow exclusion is for /module//attribute/ or /class > attribute/ annotations: > class C: >   if random.random() > 0.5: >     my_attr:int=3 >   else: >     my_attr2:float=3.5 That very example would be helpful in the FAQ, though I understand if you're

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

Given all the effort that get_type_hints() puts into evaluating those strings it seems important to spell out explicitly that they're not special. (IIRC they *are* special in PEP 563.) On Tue, Jan 12, 2021 at 8:56 AM Larry Hastings wrote: > > Yes, PEP 649 is completely agnostic about what

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

On 1/12/21 8:47 AM, Larry Hastings wrote: It seems possible to create a hybrid of these two approaches! Here's my idea: instead of the compiler storing a code object as the annotations argument to MAKE_FUNCTION, store a tuple containing the fields you'd need to /recreate/ the code object at

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

Yes, PEP 649 is completely agnostic about what values you put in as annotations.  You can put in strings, complex objects, expressions--whatever you put in, you get back out later. I'm happy to add some text to the PEP if this needs clarifying; I just thought it was obvious. Cheers,

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

On 1/11/21 5:33 PM, Inada Naoki wrote: Note that PEP 563 semantics allows more efficient implementation. Annotation is just a single constant tuple, not a dict. We already have the efficient implementation for Python 3.10. The efficient implementation in 3.10 can share tuples. If there are

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

On 1/11/21 5:37 PM, Larry Hastings wrote: I'll have to let people with large code bases speak up about this, but my understanding is that most people would prefer Python to use less memory.  On my 64-bit Linux machine, a code object is 136 bytes, its empty __dict__ is 64 bytes, [...] Oops:

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

Another thought about this PEP (hopefully my last one tonight). The section on backwards compatibility doesn't mention what should happen with annotations that are stringified by the user (as is needed for forward references in code that hasn't been PEP-563-ified yet). That's a PEP 484 feature.

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

Will do. On Mon, 2021-01-11 at 20:55 -0800, Guido van Rossum wrote: > On Mon, Jan 11, 2021 at 3:51 PM Larry Hastings > wrote: > > [...] > > > This passage in PEP 563 appears not true in Python 3.9 with > > > __future__ annotations, emphasis mine: > > > > > > > The get_type_hints() function

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

On Mon, Jan 11, 2021 at 3:51 PM Larry Hastings wrote: > [...] > > This passage in PEP 563 appears not true in Python 3.9 with __future__ > annotations, emphasis mine: > > The get_type_hints() function automatically resolves the correct value of > globalns for functions and classes. *It also

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

On Mon, Jan 11, 2021 at 1:20 PM Larry Hastings wrote: > PEP 563 states: > > For code that uses type hints, the typing.get_type_hints(obj, > globalns=None, localns=None) function correctly evaluates expressions back > from its string form. > > So, if you are passing in a localns argument that

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

On 1/11/21 6:34 PM, Paul Bryan wrote: a.__annotations__ = o assert a.__annotations__ == o Would that assert fail?  It depends on what type(o) is, which is surprising. Equally surprising?: a.__co_annotations__ = o a.__annotations__ assert a.__co_annotations__ == o Well, since you

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

On 1/11/21 6:29 PM, Greg Ewing wrote: On 12/01/21 10:41 am, Larry Hastings wrote: So: if you're using annotations for something besides "type hints", Didn't Guido decree that using annotations for anything other than type hints is no longer supported? It was never an official decree. 

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

On 12/01/21 2:56 pm, Larry Hastings wrote: In PEP 649 I think every reference of "binding" is talking about binding a code object to a globals dict to produce a function object.   The process of binding a function to an object instance to make a method is conceptually very similar, but

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

On Mon, 2021-01-11 at 17:56 -0800, Larry Hastings wrote: > On 1/11/21 5:02 PM, Paul Bryan wrote: > > > > > Some more questions... > > > > "Binding"," bound" and "unbound" code objects: > > Is your use of "binding" terminology in the PEP identical to the > > binding of a function to an object

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

On 12/01/21 11:32 am, Łukasz Langa wrote: EdgeDB uses stringified annotations exclusively which minimizes runtime memory usage of annotations because those strings are pretty much all ASCII and many can be interned. 946 -> s_schema.Schema 362 -> str 298 -> sd.CommandContext Seems to me

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

On 12/01/21 10:41 am, Larry Hastings wrote: So: if you're using annotations for something besides "type hints", Didn't Guido decree that using annotations for anything other than type hints is no longer supported? -- Greg ___ Python-Dev mailing

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

On 1/11/21 5:02 PM, Paul Bryan wrote: Some more questions... "Binding"," bound" and "unbound" code objects: Is your use of "binding" terminology in the PEP identical to the binding of a function to an object instance as a method during object creation? I'm not.  In PEP 649 I think every

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

On 1/11/21 4:55 PM, Greg Ewing wrote: On 12/01/21 6:21 am, Larry Hastings wrote: Unbound code objects ...The "annotation code object" is then stored *unbound* as the internal value of ``__co_annotations__``; it is then bound on demand when the user asks for

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

> Performance > --- > > Performance with this PEP should be favorable. In general, > resources are only consumed on demand—"you only pay for what you use". > Nice! > There are three scenarios to consider: > > * the runtime cost when annotations aren't defined, > * the runtime cost when

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

On 12/01/21 10:16 am, Larry Hastings wrote: This is addressed in PEP 563, when it rejected the idea of using "function local state when defining annotations": This would be prohibitively expensive for highly annotated code as the frames would keep all their objects alive. That includes

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

On 1/11/21 2:32 PM, Łukasz Langa wrote: 1. What do you anticipate the memory usage will look like for your solution compared to PEP 563? It depends on the scenario.  I talk about three runtime scenarios in PEP 649.  But the most relevant scenario is "annotations are defined but never

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

Some more questions... "Binding"," bound" and "unbound" code objects: Is your use of "binding" terminology in the PEP identical to the binding of a function to an object instance as a method during object creation? Function Annotations: > When binding an unbound annotation code object, a

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

On 12/01/21 6:21 am, Larry Hastings wrote: Unbound code objects ...The "annotation code object" is then stored *unbound* as the internal value of ``__co_annotations__``; it is then bound on demand when the user asks for ``__annotations__``. This seems like premature

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

On 1/11/21 3:02 PM, Paul Bryan wrote: PEP 563 does go on to state: For code which uses annotations for other purposes, a regular eval(ann, globals, locals) call is enough to resolve the annotation. And I believe this would no longer be true under PEP 649; further, localns (and maybe

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

On 2021-01-11, Łukasz Langa wrote: > The stringification process which your PEP describes as costly > only happens during compilation of a .py file to .pyc. Since > pip-installing pre-compiles modules for the user at installation > time, there is very little runtime penalty for a fully annotated >

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

On Mon, 2021-01-11 at 13:16 -0800, Larry Hastings wrote: > > Thanks for your feedback!  I'll reply piecemeal. > > On 1/11/21 12:32 PM, Paul Bryan wrote: > > > 1. Backwards Compatibility > > > > > > > PEP 563 changed the semantics of annotations. When its semantics > > > are active,

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

> On 11 Jan 2021, at 18:21, Larry Hastings wrote: > > I've written a new PEP. Please find it below. Happy reading! > Interesting! I like the clever lazy-evaluation of the __annotations__ using a pre-set code object. My only real reservation is that the transition process will be weird

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

On 1/11/21 1:16 PM, Larry Hastings wrote: On 1/11/21 12:32 PM, Paul Bryan wrote: *1. Backwards Compatibility* PEP 563 changed the semantics of annotations. When its semantics are active, annotations must assume they will be evaluated in

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

The control-flow exclusion is for /module//attribute/ or /class attribute/ annotations: class C:   if random.random() > 0.5:     my_attr:int=3   else:     my_attr2:float=3.5 Your example doesn't define any module attributes or class attributes inside flow control

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

Could you be more explicit about what is banned by the control-flow exclusion? I'm assuming that: class A: bar=float if FOO: bar=int def a(x:int, y:int)->int # function defined with annotations inside control flow return x+y

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

Thanks for your feedback!  I'll reply piecemeal. On 1/11/21 12:32 PM, Paul Bryan wrote: *1. Backwards Compatibility* PEP 563 changed the semantics of annotations. When its semantics are active, annotations must assume they will be evaluated in

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

I'm very much in favour of the this concept. A few points come to mind right away: 1. Backwards Compatibility > PEP 563 changed the semantics of annotations. When its semantics are > active, annotations must assume they will be evaluated inmodule-level > scope. They may no longer refer directly

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

On 1/11/2021 1:10 PM, Larry Hastings wrote: Certainly.  I'm just another victim in the copy-and-paste wars. I actually have write access to the PEPs repo (I'm a former release manager) so I'd be happy to check it in myself once it gets a number, however that happens.  Before I do so I'll

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

On 1/11/21 10:29 AM, Barry Warsaw wrote: Given that PEP 563 is now the default in unreleased Python 3.10, does it make sense to introduce yet another __future__ import? What would happen if you just piggybacked your idea onto that change? Part of my proposal is to deprecate PEP 563's

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

Thanks for this detailed PEP and analysis, and for the interesting discussion in your separate thread. I’m glad to see this work that we chatted about all that time before has coalesced into a PEP. FYI: For those with write access to the PEPs repo, PEP number assignments are self-serve. Just

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

On 1/11/21 10:16 AM, Chris Angelico wrote: Number allocation is pretty informal. Go ahead and grab PEP 649; It's now checked in as PEP 649, with a modern header, modern copyright, and I went ahead and grabbed the formatting stanza from the end too. Welcome to the world, baby 649! //arry/

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

On Tue, Jan 12, 2021 at 5:10 AM Larry Hastings wrote: > > > Certainly. I'm just another victim in the copy-and-paste wars. > Ah yes, the Battle of the Clipboard. Iconic, epic, such a glorious engagement! But the casualties were steep. Fortunately we can rebuild. > I actually have write access

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

Certainly.  I'm just another victim in the copy-and-paste wars. I actually have write access to the PEPs repo (I'm a former release manager) so I'd be happy to check it in myself once it gets a number, however that happens.  Before I do so I'll study PEP 12 as if it was gonna be on

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

On Tue, Jan 12, 2021 at 4:22 AM Larry Hastings wrote: > > > I've written a new PEP. Please find it below. Happy reading! > Can this get added to the PEPs repo and assigned a number and such? BTW, the currently preferred wording for the copyright blurb is slightly different. If you're the sole