On Tuesday, August 30, 2016, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 31 August 2016 at 13:37, Jack Diederich <jackd...@gmail.com > <javascript:;>> wrote: > > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum <gu...@python.org > <javascript:;>> wrote: > >> But myfunc.__annotations__ already exists -- PEP 3107 puts the > >> signature annotations there. The problem with co_annotations is that > >> annotations are evaluated (they can be quite complex expressions, e.g. > >> Optional[Tuple[int, int, some_mod.SomeClass]]), while co_varnames is > >> just a list of strings. And code objects must be immutable. The issue > >> with rejecting duplicate annotations so sternly is the same as for the > >> previous bullet. > >> > > > > If we disallow re-assignment of types as a syntax error then the conflict > > with myfunc.__annotations__ goes away for vars that share a name with the > > function arguments. The fact that variables with types can't be known > until > > the function body executes a particular line is .. I'm not sure how to > deal > > with that. For modules and classes you can assert that the body at the > top > > indent level has been executed. For functions you can only assert that it > > has been parsed. So myfunc.__annotations__ could say that the type has a > > definition but only later know what the definition is. > > What if we included local variable annotations in func.__annotations__ > as cells, like the entries in func.__closure__? > > We could also use that as a micro-optimisation technique: once the > type annotation cell is populated, CPython would just use it, rather > than re-evaluating the local variable type annotation expression every > time the function is called. > But what runtime use have the annotations on locals? They are not part of any inspectable interface. I don't want to spend any effort on them at runtime. (Just the bit that they are treated as locals.) --Guido -- --Guido (mobile)
_______________________________________________ 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