[Python-ideas] Proposal: Use mypy syntax for function annotations

[Steven D'Aprano]

As requested, I've read the whole post, and the whole thread, before 
responding :-)

On Wed, Aug 13, 2014 at 12:44:21PM -0700, Guido van Rossum wrote:

>   (a) Python should adopt mypy's syntax for function annotations
[...]

I'm very excited to see functional annotations being treated seriously, 
I think the introduction of static typing, even optional, has the 
potential to radically change the nature of Python language and I'm not 
sure if that will be good or bad :-) but it is reassuring to hear that 
the intention is that it will be treated more like an optional linter 
than as a core part of the language.

On the other hand, are you aware of Cobra, which explicitly was modelled 
on Python but with optional static typing?

http://cobra-language.com/


[...]
> *(1) A change of direction for function annotations*
> [...] I propose a conscious change of course here by stating
> that annotations should be used to indicate types and to propose a standard
> notation for them.

And in a later email, Guido also stated:

> I want to eventually phase out other uses of function annotations

That disappoints me and I hope you will reconsider.

I've spent some time thinking about using annotations for purposes other 
than type checking, but because most of my code has to run on Python 2, 
there's nothing concrete. One example is that I started exploring ways 
to use annotations as documentation for the statistics module in 3.4, 
except that annotations are banned from the standard library. (Naturally 
I haven't spent a lot of time on something that I knew was going to be 
rejected.) I came up with ideas like this:

def mean(data) -> 'μ = ∑(x)/n':

def pvariance(data) -> 'σ² = ∑(x - μ)² ÷ n':

which might have been a solution to this request:

http://bugs.python.org/issue21046

had annotations been allowed in the stdlib. Regardless of whether this 
specific idea is a good one or not, I will be disappointed if 
annotations are limited to one and only one use. I don't mind if there 
is a standard, default, set of semantics so long as there is a way to 
opt-out and use something else:

@use_spam_annotations
def frobnicate(x: spam, y: eggs)->breakfast:
    ...

for example. Whatever the mechanism, I think Python should not prohibit 
or deprecate other annotation semantics.


> *(2) A specification for what to add to Python 3.5*
> 
> There needs to be at least a rough consensus on the syntax for annotations,
> and the syntax must cover a large enough set of use cases to be useful.
> Mypy is still under development, and some of its features are still
> evolving (e.g. unions were only added a few weeks ago). It would be
> possible to argue endlessly about details of the notation, e.g. whether to
> use 'list' or 'List', what either of those means (is a duck-typed list-like
> type acceptable?) or how to declare and use type variables, and what to do
> with functions that have no annotations at all (mypy currently skips those
> completely).

It doesn't sound to me like the mypy syntax is mature enough to bless, 
let alone to start using it in the standard library.


> I am proposing that we adopt whatever mypy uses here, keeping discussion of
> the details (mostly) out of the PEP. The goal is to make it possible to add
> type checking annotations to 3rd party modules (and even to the stdlib)
> while allowing unaltered execution of the program by the (unmodified)
> Python 3.5 interpreter. The actual type checker will not be integrated with
> the Python interpreter, and it will not be checked into the CPython
> repository. The only thing that needs to be added to the stdlib is a copy
> of mypy's typing.py module. 

What happens when the typing.py module in the standard library gets out 
of sync with the typing.py module in mypy?


[...]
> *Appendix -- Why Add Type Annotations?*
> The argument between proponents of static typing and dynamic typing has
> been going on for many decades. Neither side is all wrong or all right.
> Python has traditionally fallen in the camp of extremely dynamic typing,
> and this has worked well for most users, but there are definitely some
> areas where adding type annotations would help.

Some people have probably already seen this, but I have found this 
article to be very useful for understanding why static and dynamic type 
checking can be complementary rather than opposed:

http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/



-- 
Steven