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

[Haoyi Li]

> Both solutions have merit, but the idea of some implementations of the
type checker having covariance and some contravariance is fairly disturbing.

Why can't we have both? That's the only way to properly type things, since
immutable-get-style APIs are always going to be convariant, set-only style
APIs (e.g. a function that takes 1 arg and returns None) are going to be
contravariant and mutable get-set APIs (like most python collections)
should really be invariant.


On Wed, Aug 13, 2014 at 5:32 PM, Chris Angelico <rosuav at gmail.com> wrote:

> On Thu, Aug 14, 2014 at 5:44 AM, Guido van Rossum <guido at python.org>
> wrote:
> >   from typing import List, Dict
> >
> >   def word_count(input: List[str]) -> Dict[str, int]:
> >       result = {}  #type: Dict[str, int]
> >       for line in input:
> >           for word in line.split():
> >               result[word] = result.get(word, 0) + 1
> >       return result
>
> I strongly support the concept of standardized typing information.
> There'll be endless bikeshedding on names, though - personally, I
> don't like the idea of "from typing import ..." as there's already a
> "types" module and I think it'd be confusing. (Also, "mypy" sounds
> like someone's toy reimplementation of Python, which it does seem to
> be :) but that's not really well named for "type checker using stdlib
> annotations".) But I think the idea is excellent, and it deserves
> stdlib support.
>
> The cast notation sounds to me like it's what Pike calls a "soft cast"
> - it doesn't actually *change* anything (contrast a C or C++ type
> cast, where (float)42 is 42.0), it just says to the copmiler/type
> checker "this thing is actually now this type". If the naming is clear
> on this point, it leaves open the possibility of actual recursive
> casting - where casting a List[str] to List[int] is equivalent to
> [int(x) for x in lst]. Whether or not that's a feature worth adding
> can be decided in the distant future :)
>
> +1 on the broad proposal. +0.5 on defining the notation while leaving
> the actual type checking to an external program.
>
> ChrisA
> _______________________________________________
> 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/20140813/a1d1c34c/attachment.html>