Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations (Draft 3)

Congratulations, Łukasz! -- Ivan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations (Draft 3)

Łukasz, I am hereby accepting your PEP. This will be a great improvement in the experience of users annotating large complex codebases. Congrats on the design and implementation and on your shepherding the PEP through the discussion phase. Also a special thanks to Serhiy for thoroughly reviewing a

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

See my response to Mark's e-mail. I agree that special-casing outermost strings is not generic enough of a solution and will be removing this special handling from the PEP and the implementation. - Ł > On Nov 19, 2017, at 2:38 PM, Koos Zevenhoven wrote: > > On Mon, Nov 13, 2017 at 11:59 PM, B

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Mon, Nov 13, 2017 at 11:59 PM, Brett Cannon wrote: ​[..]​ > On Sun, Nov 12, 2017, 10:22 Koos Zevenhoven, wrote: > ​​ > >> >> There's two thing I don't understand here: >> >> * What does it mean to preserve the string verbatim? No matter how I read >> it, I can't tell if it's with quotes or wi

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Sun, Nov 12, 2017, 10:22 Koos Zevenhoven, wrote: > On Nov 12, 2017 19:10, "Guido van Rossum" wrote: > > On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven > wrote: > >> So actually my question is: What should happen when the annotation is >> already a string literal? >> > > The PEP answers tha

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 12, 2017 19:10, "Guido van Rossum" wrote: On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven wrote: > So actually my question is: What should happen when the annotation is > already a string literal? > The PEP answers that clearly (under Implementation): > If an annotation was already a

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Sun, Nov 12, 2017 at 4:14 AM, Koos Zevenhoven wrote: > So actually my question is: What should happen when the annotation is > already a string literal? > The PEP answers that clearly (under Implementation): > If an annotation was already a string, this string is preserved > verbatim. -- -

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Sun, Nov 12, 2017 at 7:07 AM, Guido van Rossum wrote: > On Fri, Nov 10, 2017 at 11:02 PM, Nick Coghlan wrote: > >> On 11 November 2017 at 01:48, Guido van Rossum wrote: >> > I don't mind the long name. Of all the options so far I really only like >> > 'string_annotations' so let's go with th

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Fri, Nov 10, 2017 at 11:02 PM, Nick Coghlan wrote: > On 11 November 2017 at 01:48, Guido van Rossum wrote: > > I don't mind the long name. Of all the options so far I really only like > > 'string_annotations' so let's go with that. > > +1 from me. > I'd like to reverse my stance on this. We

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 11 November 2017 at 01:48, Guido van Rossum wrote: > I don't mind the long name. Of all the options so far I really only like > 'string_annotations' so let's go with that. +1 from me. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia __

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 19:17, Greg Ewing wrote: > Ethan Furman wrote: > >> Contriwise, "annotation_strings" sounds like a different type of >> annotation -- they are now being stored as strings, instead of something >> else. >> > > How about "annotations_as_strings"? That feels unambiguous. "an

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

Ethan Furman wrote: Contriwise, "annotation_strings" sounds like a different type of annotation -- they are now being stored as strings, instead of something else. How about "annotations_as_strings"? -- Greg ___ Python-Dev mailing list Python-Dev@py

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 10 Nov, 2017, at 4:48 PM, Guido van Rossum wrote: > > On Fri, Nov 10, 2017 at 1:20 AM, Lukasz Langa > wrote: > Alright, we're on bikeshed territory now. Finally! :-) > > I was always thinking about this as "static annotations". The fact they're > strings at runtim

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Fri, Nov 10, 2017 at 9:50 AM, Ethan Furman wrote: > On 11/10/2017 07:48 AM, Guido van Rossum wrote: > > I don't mind the long name. Of all the options so far I really only like >> 'string_annotations' so let's go with that. >> > > As someone else mentioned, we have function annotations and var

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Fri, Nov 10, 2017 at 7:50 PM, Ethan Furman wrote: > On 11/10/2017 07:48 AM, Guido van Rossum wrote: > > I don't mind the long name. Of all the options so far I really only like >> 'string_annotations' so let's go with that. >> > > As someone else mentioned, we have function annotations and var

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 11/10/2017 07:48 AM, Guido van Rossum wrote: I don't mind the long name. Of all the options so far I really only like 'string_annotations' so let's go with that. As someone else mentioned, we have function annotations and variable annotations already, which makes string_annotations sound

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Fri, Nov 10, 2017 at 1:20 AM, Lukasz Langa wrote: > Alright, we're on bikeshed territory now. Finally! :-) > > I was always thinking about this as "static annotations". The fact they're > strings at runtime is irrelevant for most people who will use this future. > They don't want string annota

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Thu, Nov 9, 2017 at 9:51 PM, Guido van Rossum wrote: > If we have to change the name I'd vote for string_annotations -- "lazy" > has too many other connotations (e.g. it might cause people to think it's > the thunks). I find str_annotations too abbreviated, and > stringify_annotations is too h

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 19:20, Lukasz Langa wrote: > Alright, we're on bikeshed territory now. Finally! :-) > > I was always thinking about this as "static annotations". The fact they're > strings at runtime is irrelevant for most people who will use this future. It's highly relevant to anyone cur

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

Alright, we're on bikeshed territory now. Finally! :-) I was always thinking about this as "static annotations". The fact they're strings at runtime is irrelevant for most people who will use this future. They don't want string annotations, they want them to not be evaluated on import time... t

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 16:42, Victor Stinner wrote: > I didn't follow the discussion on the PEP but I was surprised to read "from > __future__ import annotations" in an example. Annotations exist since Python > 3.0, why would Python 3.7 require a future for them? Well, I was aware of > the PEP, bu

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

I didn't follow the discussion on the PEP but I was surprised to read "from __future__ import annotations" in an example. Annotations exist since Python 3.0, why would Python 3.7 require a future for them? Well, I was aware of the PEP, but I was confused anyway. I really prefer "from __future__ im

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 11/9/2017 9:11 PM, Nick Coghlan wrote: On 10 November 2017 at 05:51, Guido van Rossum wrote: If we have to change the name I'd vote for string_annotations -- "lazy" has too many other connotations (e.g. it might cause people to think it's the thunks). I find str_annotations too abbreviated,

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

So... Łukasz? On Thu, Nov 9, 2017 at 6:11 PM, Nick Coghlan wrote: > On 10 November 2017 at 05:51, Guido van Rossum wrote: > > If we have to change the name I'd vote for string_annotations -- "lazy" > has > > too many other connotations (e.g. it might cause people to think it's the > > thunks).

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 10 November 2017 at 05:51, Guido van Rossum wrote: > If we have to change the name I'd vote for string_annotations -- "lazy" has > too many other connotations (e.g. it might cause people to think it's the > thunks). I find str_annotations too abbreviated, and stringify_annotations > is too hard

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

If we have to change the name I'd vote for string_annotations -- "lazy" has too many other connotations (e.g. it might cause people to think it's the thunks). I find str_annotations too abbreviated, and stringify_annotations is too hard to spell. On Thu, Nov 9, 2017 at 11:39 AM, Barry Warsaw wrot

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 8, 2017, at 23:57, Nick Coghlan wrote: > Putting that quibble first: could we adjust the feature flag to be > either "from __future__ import lazy_annotations" or "from __future__ > import str_annotations"? > > Every time I see "from __future__ import annotations" I think "But > we've had

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

Guido van Rossum wrote: I did not assume totally opaque -- but code objects are not very introspection friendly (and they have no strong compatibility guarantees). If I understand the proposal correctly, there wouldn't be any point in trying to introspect the lambdas/thunks/whatever. They're on

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

TL;DR version: I'm now +1 on a string-based PEP 563, with one relatively small quibble regarding the future flag's name. Putting that quibble first: could we adjust the feature flag to be either "from __future__ import lazy_annotations" or "from __future__ import str_annotations"? Every time I se

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Wed, Nov 8, 2017 at 5:49 PM, Nick Coghlan wrote: > On 8 November 2017 at 16:24, Guido van Rossum wrote: > > I also don't like the idea that there's nothing you can do with a thunk > > besides calling it -- you can't meaningfully introspect it (not without > > building your own bytecode interp

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 8 November 2017 at 16:24, Guido van Rossum wrote: > I also don't like the idea that there's nothing you can do with a thunk > besides calling it -- you can't meaningfully introspect it (not without > building your own bytecode interpreter anyway). Wait, that wasn't what I was suggesting at all

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

To top off today's set of hopeful thread closures I want to put this one to rest. While I'm not ready to accept PEP 563 yet (I'm waiting for the first cut of the implementation) I *am* hereby nixing the thunk idea. When I said I was more worried about that than about the stringification that wasn

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 7 November 2017 at 09:20, Lukasz Langa wrote: > > >> On Nov 5, 2017, at 11:28 PM, Nick Coghlan wrote: >> >> On 6 November 2017 at 16:36, Lukasz Langa wrote: >> >> - compile annotations like a small nested class body (but returning >> the expression result, rather than None) >> - emit MAKE_THU

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

As memory footprint and import time point of view, I prefer string to thunk. We can intern strings, but not lambda. Dict containing only strings is not tracked by GC, dict containing lambdas is tracked by GC. INADA Naoki On Tue, Nov 7, 2017 at 8:20 AM, Lukasz Langa wrote: > > >> On Nov 5, 201

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On Nov 5, 2017, at 11:28 PM, Nick Coghlan wrote: > > On 6 November 2017 at 16:36, Lukasz Langa wrote: > > - compile annotations like a small nested class body (but returning > the expression result, rather than None) > - emit MAKE_THUNK instead of the expression's opcodes > - emit STORE_ANN

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Sun, 5 Nov 2017 20:18:07 -0800 Lukasz Langa wrote: > > Interestingly enough, at Facebook we found out that using f-strings is > *faster* at runtime than the lazy form of logging.log("format with %s and > %d", arg1, arg2), including for cases when the log message is not emitted. I suspect th

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 6 November 2017 at 16:36, Lukasz Langa wrote: > > On 5 Nov, 2017, at 9:55 PM, Nick Coghlan wrote: > > Python's name resolution rules are already ridiculously complicated, > and PEP 563 is proposing to make them *even worse*, purely for the > sake of an optional feature primarily of interest to

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 5 Nov, 2017, at 9:55 PM, Nick Coghlan wrote: > > Python's name resolution rules are already ridiculously complicated, > and PEP 563 is proposing to make them *even worse*, purely for the > sake of an optional feature primarily of interest to large enterprise > users. Solving forward refere

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 6 November 2017 at 14:40, Lukasz Langa wrote: > On 4 Nov, 2017, at 6:32 PM, Nick Coghlan wrote: >> The only workaround I can see for that breakage is that instead of >> using strings, we could instead define a new "thunk" type that >> consists of two things: > >> 1. A code object to be run wit

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 4 Nov, 2017, at 6:32 PM, Nick Coghlan wrote: > > The PEP's current attitude towards this is "Yes, it will break, but > that's OK, because it doesn't matter for the type annotation use case, > since static analysers will still understand it". Adopting such a > cavalier approach towards backw

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On 4 Nov, 2017, at 11:43 AM, Peter Ludemann via Python-Dev > wrote: > > If type annotations are treated like implicit lambdas, then that's a first > step to something similar to Lisp's "special forms". A full generalization of > that would allow, for example, logging.debug to not evaluate i

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 5 November 2017 at 02:42, Guido van Rossum wrote: > I'm very worried about trying to come up with a robust implementation of > this in under 12 weeks. By contrast, the stringification that Łukasz is > proposing feels eminently doable. I'm far from confident about that, as the string proposal i

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

If type annotations are treated like implicit lambdas, then that's a first step to something similar to Lisp's "special forms". A full generalization of that would allow, for example, logging.debug to not evaluate its args unless debugging is turned on (I use a logging.debug wrapper that allows lam

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

I'm very worried about trying to come up with a robust implementation of this in under 12 weeks. By contrast, the stringification that Łukasz is proposing feels eminently doable. On Sat, Nov 4, 2017 at 6:51 AM, Nick Coghlan wrote: > On 4 November 2017 at 00:40, Guido van Rossum wrote: > > IMO t

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 4 November 2017 at 00:40, Guido van Rossum wrote: > IMO the inability of referencing class-level definitions from annotations on > methods pretty much kills this idea. If we decided we wanted to make it work, I think the key runtime building block we would need is a new kind of cell reference:

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 3, 2017, at 17:09, Luca Sbardella wrote: > > Impressive stats! I didn’t know this command, thanks! Neither did I until a day or so ago. I already only want to use Python 3.7. :) -Barry signature.asc Description: Message signed with OpenPGP ___

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

Impressive stats! I didn’t know this command, thanks! On Fri, 3 Nov 2017 at 20:47, Barry Warsaw wrote: > On Nov 2, 2017, at 23:22, Nick Coghlan wrote: > > Another point worth noting is that merely importing the typing module > > is expensive: > > > > $ python -m perf timeit -s "from importlib i

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Nov 2, 2017, at 23:22, Nick Coghlan wrote: > Another point worth noting is that merely importing the typing module > is expensive: > > $ python -m perf timeit -s "from importlib import reload; import > typing" "reload(typing)" > . > Mean +- std dev: 10.6 ms +- 0.6 ms > > 1

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

IMO the inability of referencing class-level definitions from annotations on methods pretty much kills this idea. On Thu, Nov 2, 2017 at 11:27 PM, Nick Coghlan wrote: > On 3 November 2017 at 04:39, Jukka Lehtosalo wrote: > >> > * forward references: when a type hint contains names that have not

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 3 November 2017 at 04:39, Jukka Lehtosalo wrote: >> > * forward references: when a type hint contains names that have not been >> > defined yet, that definition needs to be expressed as a string >> > literal; >> >> After all the discussion, I still don't see why this is an issue. >> Strings

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 3 November 2017 at 03:00, Brett Cannon wrote: > The cost of constructing some of the objects used as type hints can be very > expensive and make importing really expensive (this has been pointed out by > Lukasz previously as well as Inada-san). By making Python itself not have to > construct ob

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

I'm 100% agree with Łukasz and Brett. +1 and thanks for writing this PEP. INADA Naoki On Fri, Nov 3, 2017 at 2:00 AM, Brett Cannon wrote: > > > On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano wrote: >> >> On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: >> >> > PEP: 563 >> > Title: P

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

> On Nov 2, 2017, at 1:13 PM, Stéfane Fermigier wrote: > > Another common use case is dependency injection / IoC: > > - Injector (https://github.com/alecthomas/injector > ): > - Flask-Injector (ok it's the same underlying injector): Pretty cool! This is

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Thu, Nov 2, 2017 at 7:39 PM, Jukka Lehtosalo wrote: > > As type checking has become the main use case for annotations, using > annotations without a type checker is fast becoming a marginal use case. > Type checkers can easily and reliably validate that names in annotations > aren't > misspel

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 1 November 2017 at 23:48, Lukasz Langa wrote: > Runtime annotation resolution and class decorators > -- > > Metaclasses and class decorators that need to resolve annotations for > the current class will fail for annotations that use the name of t

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On 2 November 2017 at 18:00, Brett Cannon wrote: > > > On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano wrote: > >> On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: >> [...snip...] > > I think the performance bit is really the big deal here. > > I don't think so. Although subscripting ge

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Thu, Nov 2, 2017 at 3:45 PM, Steven D'Aprano wrote: > On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: > > > This PEP proposes changing function annotations and variable annotations > > so that they are no longer evaluated at function definition time. > > Instead, they are preserv

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Thu, 2 Nov 2017 at 08:46 Steven D'Aprano wrote: > On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: > > > PEP: 563 > > Title: Postponed Evaluation of Annotations > > > This PEP proposes changing function annotations and variable annotations > > so that they are no longer evaluated

Re: [Python-Dev] PEP 563: Postponed Evaluation of Annotations

On Wed, Nov 01, 2017 at 03:48:00PM -0700, Lukasz Langa wrote: > PEP: 563 > Title: Postponed Evaluation of Annotations > This PEP proposes changing function annotations and variable annotations > so that they are no longer evaluated at function definition time. > Instead, they are preserved in ``_