[Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations
Nick Coghlan
ncoghlan at gmail.com
Wed Aug 31 01:11:23 EDT 2016
On 31 August 2016 at 13:37, Jack Diederich <jackdied at gmail.com> wrote:
> On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum <guido at python.org> 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.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list