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

[Guido van Rossum]

On Tue, Jan 20, 2015 at 9:09 PM, Greg Ewing <greg.ewing at canterbury.ac.nz>
wrote:

> Andrew Barnert wrote:
>
>> But I think there's a hole in the premise. Python's key strength is good
>> debug-ability and amazingly powerful introspection. (I mean Python's _two_
>> key strengths are...) Information that has no runtime meaning to the
>> interpreter may still have meaning to the user who's debugging code,
>>
>
> There's nothing wrong with making the annotations *available*
> at run time. All I'm saying is that *evaluating* them at run
> time hinders rather than helping for the intended use.


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.
Surely if you are reference a class that's not a built-in you have to
import it before you can reference in a type hint -- otherwise how would
the type checker know where to look for the class definition?

FWIW if you really don't want to have them evaluated at run time, you can
just put all type hints in string quotes. mypy will treat them as forward
references, but AFAIC it doesn't insist that a forward reference contains
at least one symbol that is not defined yet at the place where it occurs.
:-) I doubt that this style has many things to recommend it though (see
previous paragraph).

Let me also use this response to explain why I think "::" is a bad idea:

- First and foremost, Python usually (an d intentionally!) uses punctuation
in a way derived from or similar to long-standing traditions for written
text and basic math (with a few going back to old programming conventions,
like using * for multiplication). The single colon used for type
annotations is an example of this: it is analogous to the way the colon is
often used in prose. 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. Decorator syntax notwithstanding, magical
operators are and should remain rare in Python. 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 want the type checker to work for earlier versions of Python 3 as well,
so that library maintainers (at least for code that doesn't need to support
Python 2) can start including type hints in their code without locking that
code in to Python 3.5 -- they can use a backport of the (run time) typing
package from PyPI, and the type checker can handle earlier Python versions
just fine. (All of this already works for mypy.)

- What would you do for function return type hints? "-->" or "->>" or "->:"
or "->->" all look completely arbitrary.

- Looking ahead, if type hints are successful we might want to add a
similar notation to declare the type of variables or class attributes, for
example "age: int = 99" or perhaps "var age: int = 99". But if we were to
use "::" for type hints in function definitions, for consistency we would
have to use "age:: int = 99", which would just perpetuate the syntactic
hack.

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