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

[Gregory P. Smith]

On Thu Aug 14 2014 at 1:06:20 PM Dennis Brakhane <brakhane at googlemail.com>
wrote:

> Am 13.08.2014 23:46, schrieb Guido van Rossum:
> >
> >
> > Mypy has a cast() operator that you can use to shut it up when you
> > (think you) know the conversion is safe.
> >
> Does Mypy provide a way to "fix/monkeypatch" incorrect type declarations
> in function signatures? For example, by modifying __annotations__?
>
> My pet peeve of static languages is that programmers are often too
> fixated on their particular problem that they don't think about alternate
> uses for their code and make the type declarations uncessarily complex.
>
> For example, in Java nearly every method in Java that deals with
> character strings uses "String" as parameter type, while they should
> have used "CharSequence". Having to read an entire input stream and
> storing it in a String just to be able to use a method is not fun
> (String is final in Java)
>
> I'm worried that in Python we will have utility functions that declare
> they require a List[int], when in fact they actually only require a
> Sequence[int] or
> Sequence[Number].
>
>
This always happens, even in docstrings where people state types today. For
example, I often correct people during code reviews to say sequence of
instead of list of in docstrings. Nothing can really prevent that beyond
documentation about annotations having good examples and promoting the use
of concept or interface annotations over specific type annotations.

But what's being proposed here isn't a strict static type check, it's an
annotation.  Sure, if someone misannotates their code and runs it through a
"compile time" checker (aka superlint) such as mypy or something even more
advanced, it will highlight problems where there may in fact be none. But
the problem being highlighted there is that the annotation is wrong.

Any system doing that level of code analysis will need a way to deal with
loading corrected annotations for code that for some reason cannot be
changed directly in the annotated files themselves (standard library, third
party library from pypi, etc). But this is really no different than loading
annotations for extension modules and the stdlib builtins. Those are
already likely to be separate files declaring interface annotations only
(there is a pile of these that we've generated via code analysis for
builtins and parts of the stdlib in the pytypedecl repo, expect more of
that to come from anyone working on this kind of thing).

While Mypy's cast is nice in that I won't have to wrap my Integer Tuple
> in list like object, having to cast it every time I use a particular
> broken utility method
> feels very ugly to me; and defining a wrapper function with the correct
> type information feels like unnecessary run time overhead for no gain.
>
> Don't get me wrong, I'm not entirely against some kind of type checking,
> but I fear that there must exist possible workarounds for badly written
> code.
>

always.  but this is more a task for all checker implementations.  not
something the syntax for annotations itself can prevent.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140815/fc34037f/attachment.html>