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... they want them to be static. Also, "static typing" et al. I think it has a nice vibe to it.
I admit "annotations" is too broad but "static_annotations" (or "string_annotations" ¯\_(ツ)_/¯ ) will be the longest __future__ name so far. That was my main motivation behind using the shorter name. And a bit of megalomania I guess. - Ł > On 9 Nov, 2017, at 7:30 PM, Guido van Rossum <gu...@python.org> wrote: > > So... Łukasz? > > On Thu, Nov 9, 2017 at 6:11 PM, Nick Coghlan <ncogh...@gmail.com > <mailto:ncogh...@gmail.com>> wrote: > On 10 November 2017 at 05:51, Guido van Rossum <gu...@python.org > <mailto:gu...@python.org>> 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 to spell. > > Aye, I'd be fine with "from __future__ import string_annotations" - > that's even more explicitly self-documenting than either of my > suggestions. > > -- > --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 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
