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

[Sunjay Varma]

+1 This is definitely something to consider.

One of the many benefits of Python is that you can use objects with
equivalent interfaces in functions that may not have expected that type
while they were being written.

One thing to note: if we try to make this syntax too verbose, it may lose
all of its purpose all together.

For example: one (bad) solution to support what I described above is to
define some sort of convoluted syntax for specifying the exact interface a
function supports. At this point, any addition to the language would do
nothing but hinder it. Anything that verbose loses is too complex to be
valuable.

We have to be careful with this. If we do accept it (or any of the many
alternatives suggested so far), then we should choose a few use cases and
focus on solving them as best as possible.

On Aug 14, 2014 4:06 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].
>
> 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.
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140814/191ebbf6/attachment.html>