[Python-ideas] Annotations (and static typing)

[Paul Moore]

Sigh. I go away for a week and come back to a mega-thread I can never
hope to catch up on :-)

TL; DR; - Although mypy looks interesting, I think it's too soon to
close the door on all other uses of annotations. Let's find a solution
that allows exploration of alternative uses for a while longer.

OK, can I just make some points regarding the static typing thread.
First of all, I have no issue with the idea of static typing, and in
fact I look forward to seeing what benefits it might have (if nothing
else, the pointer to mypy, which I'd never heard of before, is
appreciated). It won't be something I use soon (see below) but that's
fine.

But Guido seems to be saying (on a number of occasions) that nobody is
really using annotations, so he wants to focus on the static typing
use case alone. I think this is a mistake. First of all, I see no
reason why functions using typing annotations could not be introduced
with a decorator[1]. So why insist that this is the *only* use of
annotations, when it's pretty easy to allow others to co-exist?

Also, the "nobody is using annotations" argument? Personally, I know
of a few other uses:

1. Argument parsers - at least 3 have been mentioned in the thread.
2. Structure unpacking - I think there is a library that uses
annotations for this, although I may be wrong.
3. FFI bindings. I know I've seen this discussed, although I can't
find a reference just now.

There are probably other ideas around as well (GUI bindings,
documentation generation, ...) None are particularly mature, and most
are just at the "ideas" stage, but typically the ideas I have seen are
the sort of thing you'd write a library for, and Python 3 only
libraries *really* aren't common yet.

The problem for people wanting to experiment with annotations, is that
they need to be writing Python 3 only code. While Python 3 adoption is
growing rapidly, I suspect that large applications are typically still
focused on either going through, or tidying up after, a 2-3 migration.
And new projects, while they may be developed from the ground up using
Python 3, will typically be using programmers skilled in Python 2, to
whom Python 3 features are not yet an "instinctive" part of the
toolset. Apart from large standalone applications, there are smaller
scripts (which are typically going to be too small to need
programming-in-the-large features like annotations) and libraries
(which really aren't yet in a position to drop Python 2.x totally,
unless they have a fairly small user base).

So I don't see it as compelling that usage of annotations in the wild
is not yet extensive.

Rather than close the door on alternative uses of annotations, can I suggest:

1. By all means bless mypy syntax as the standard static typing
notation - this seems like a good thing.
2. Clarify that static typing annotations should be introduced with a
decorator. Maybe reserve a decorator name ("@typed"?) that has a dummy
declaration in the stdlib, and have a registration protocols for tools
to hook their own implementation into it.[2]
3. Leave the door open for other uses of decorators, at least until
some of the more major libraries drop Python 2.x support completely
(and hence can afford to have a dependency on a Python 3 only module
that uses annotations). See at that stage if annotations take off.
4. If we get to a point where even libraries that *could* use
annotations don't, then revisit the idea of restricting usage to just
type information.

Paul

[1] Also, a decorator could allow a Python 2 compatible form by using
decorator arguments as an alternative to annotations.
[2] I've yet to see a clear explanation of how "a tool using type
annotations" like an linter, editor, IDE or Python compiler would use
them in such a way that precludes decoration as a means of signalling
the annotation semantics.