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
On Thu, Aug 14, 2014 at 5:44 AM, Guido van Rossum
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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/