[Python-ideas] Optional static typing -- the crossroads

[Stefan Behnel]

Guido van Rossum schrieb am 17.08.2014 um 07:03:
> I'd like to summarize the main issues that have come up. As an experiment,
> I'm not changing the subject, but I am still not quoting anything in
> particular. Only two issues (or issue clusters) really seem contentious:
> 
> (1) Should the function annotation syntax (eventually) be reserved for type
> annotations in a standard syntax? Or can multiple different uses of
> annotations coexist? And if they can, how should a specific use be
> indicated? (Also, some questions about compile-time vs. run-time use.)
>
> Regarding (1), I continue to believe that we should eventually reserve 
> annotations for types, to avoid confusing both humans and tools, but I 
> think there's nothing we have to do in 3.5 -- 3.5 must preserve
> backward compatibility, and we're not proposing to give annotations any
> new semantics anyway -- the actual changes to CPython are limited to a
> new stdlib module (typing) and some documentation.

As I mentioned before, there is more than one kind of type, even if we
stick to reserving annotations for type declarations. That's why Cython
currently supports these four ways of type annotations (in addition to its
own non-Python way with "cdef"):

    x: dict
    x: {"type": dict}
    x: {"type": "dict"}
    x: {"ctype": "long double"}

The latter three can also be combined, so you could declare a C type for
Cython compilation and a Python type for your IDE and other static Python
analysis tools, e.g.

    x: {"type": int, "ctype": "size_t"}

Note that this also helps at a documentation level. The expected input is a
Python int, but in fact it's restricted to a C size_t by the native
implementation.

I'd still vote for allowing the simpler "x: dict" as well for cases where
it's the only annotation. It's easy enough to switch to the explicit
notation when you want to add a second (potentially non-type) annotation.

So, rather than "reserving" annotations for type declarations, I vote for
making type annotations the default, but allowing other annotations by
putting them into a dict that gives each annotation a string name. That
name could be a module name in the stdlib or on PyPI, for example.


> (2) For type annotations, should we adopt (roughly) the mypy syntax or the
> alternative proposed by Dave Halter? This uses built-in container notations
> as a shorthand, e.g. {str: int} instead of Dict[str, int]. This also
> touches on the issue of abstract vs. concrete types (e.g. iterable vs.
> list).

I talked to him at EP14 and we agreed that the simpler syntax looks
tempting. However, it does not support protocols, so it still needs
something that allows us to say Iterable(int) in some way. I always thought
that the ABCs were made for that, but so far everyone seemed to think that
we need something different again. I'm happy to see that your preference
also goes in that direction now. Having yet another typing module seems
like an unnecessary duplication of the type system.

Stefan