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

[Guido van Rossum]

On Wed, Jan 21, 2015 at 2:18 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Guido van Rossum wrote:
>
>> That's debatable. While evaluating them at run time causes some issues
>> with forward references (mostly for container-ish class definitions), it
>> also catches many mistakes early, such as not importing the referenced
>> classes.
>>
>
> Wouldn't the static type checker catch that even earlier?
> If you reference something in a type expression that you
> haven't imported, the static checker won't know what it
> means, so surely it must complain.
>

But the static checker is like a linter and it's common to run those
infrequently (e.g. only when submitting a diff for review) while running
unittests frequently (e.g. whenever the developer has written some new
code). Assuming you have fast unittests.


>  Switching to a double colon would make it a magical operator --
>> especially since a single colon in the same position would have a similar
>> but different meaning.
>>
>
> I don't see how it's any more magical than '==' being a
> distinct token rather than just two '=' tokens in a row,
> and 'x == 2' having a different meaning from 'x = 2'.
>

It's different because == is used in nearly all languages in common use
(certainly all in the TIOBE top 10) while :: would be a brand new invention
here (unrelated to e.g. C++'s :: scoping operator).


>  Eight years ago we picked the winning syntax for argument annotations. It
>> would be tragic if we now were to replace it with this syntactic hack.
>>
>
> I think it's tragic that we seem to have painted ourselves
> into a corner where we can't give that winning syntax the
> semantics that would be best for what we've now decided on
> as the winning use case.
>

To the contrary, I don't think it's tragic at all. It's how most Python
evolution happens. mypy wouldn't have happened the way it did if we didn't
have annotations: Jukka's original plan was a custom language, which would
have made it just one more Ph.D. project without any users.


> How about we just deprecate relying on run-time evaluation
> of argument annotations? You've pretty much declared that
> all existing uses of them are deprecated, so it wouldn't
> cause much more breakage in the long run, and it would give
> us a way out of the corner in the future if we wanted.


I don't see a way to get there from here. Talking about deprecating them is
cheap -- actually breaking the code can't happen until 3.6 at the earliest
(if we were to issue deprecation warnings by default in 3.5 for every
annotation that's not a class or imported from typing), or 3.7
realistically (if in 3.5 we document the deprecation but don't act on it).
The provisional status of PEP 484 makes even the more conservative scenario
unlikely.

And, having coded up much of a possible typing.py module already (
https://github.com/ambv/typehinting/tree/master/prototyping) I really don't
see the big problem with run-time evaluation of constraints.

-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150121/d70f110d/attachment.html>