[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Devin Jeanpierre]

On Tue, Jan 20, 2015 at 4:20 PM, Eugene Toder <eltoder at gmail.com> wrote:
> On Tue, Jan 20, 2015 at 6:23 PM, Andrew Barnert
> <abarnert at yahoo.com.dmarc.invalid> wrote:
>>
>> As I understand it (and please correct me if I'm wrong), Greg is making a
>> very simple point:
>>
>> If type annotations are only for static type checking, as done by
>> something like MyPy, they, by definition, have no use at runtime. But
>> annotations are about storing information with functions at runtime. So the
>> proposal is inherently storing useless information at runtime. (And it's
>> also preventing anyone else from storing useful information there, but
>> that's not the main issue.)
>
> I believe the argument is slightly different. The main issue is not with
> storing the annotation, but with evaluating it. This evaluation does not
> help a static type checker in any way, but introduces problems with forward
> references, and limits the syntax. For example, a type checker could support
> the common and natural "T1|T2" syntax for the Union type if the interpreter
> did not attempt to evaluate it. The current solution is to abandon some
> syntax, and put other things in quotes, which is a bit ugly.
>
> The second issue is that the annotations are only supported on the function
> arguments and return value. There are other things that are useful to
> annotate, most obviously class attributes and local variables. The current
> solution is to put these annotations into comments, which is not pretty too.

I would add a third problem: Evaluating at runtime fools people into
thinking that this is Python code. In fact, the linter is only able to
evaluate very few things, and it might even evaluate them differently
to how Python does. This will be a source of confusion and bugs.

> I think these are both good points. They can be addressed by introducing an
> entirely new syntax, like suggested above, or by changing and extending how
> the current syntax works. E.g. one can imagine that annotations are not
> evaluated. They are always stored as strings for the benefit of
> introspection, but otherwise are not touched by the interpreter. Also,
> syntax is added to put annotations on other constructs. At least for the 2
> cases above it should not be not hard, and we can store these new
> annotations on the class object and on the function object respectively.
> Obviously not evaluating annotations is a breaking change, so it can be a
> non-starter, but it will make things cleaner.

This is an interesting idea. Since the original stated purpose of
annotations is being overridden to be for mypy style type checkers,
the normal backwards compatibility rules maybe don't apply as
strongly.

-- Devin