[Python-ideas] Optional static typing -- the crossroads

[Andrew Barnert]

On Aug 16, 2014, at 6:00, Dave Halter <davidhalter88 at gmail.com> wrote:

> Appendix (My Proposal)
> 
> My proposal (as discussed and evolved with a few good people at EuroPython) for containers would look something like this:
> 
>     def foo(index: int, x: [float], y: {int: str}) -> (float, str):
>         return x[index], y[index]
> 
> The "default" containers (set, list, dict and tuple) would just serve as a way of specifying containers. This makes a lot of things less complicated:
> 
> - It's easier to understand (everybody knows builtin types). It also feels natural to me. The example above covers also almost all variations. A tuple could be expanded by using the ellipsis: `(int, object, ..., float)`.
> - No imports needed. People are more likely to use it, if they don't have to import typing all the time. This is important for static analysis, people are only likely to use it if it's easier than writing docstrings with type information.
> - Argument clinic could use the same. The standard library quite often doesn't accept abstract data types, btw. 
> - It's what people sometimes use in docstrings: ``@rtype: (float, str)`` or ``:rtype: (float, str)``.
> 
> I know this doesn't solve the duck typing issue, but if you look at real-life Python code bases, there are very few instances of actually implementing a ``Mapping``, etc.

For "Mapping", maybe (although anyone who uses some form of tree-based mapping, either to avoid hash-collision attacks or because he needs sorting, may disagree).

But for "etc.", people implement them all the time. Especially "Iterable" and "Callable". And, even some of the ones that people don't implement often, they use often, implicitly or otherwise, like TextIOBase.

Anything that encourages people to restrict their code to only working on lists instead of iterables would be a huge step backward to Python 2.2. And your argument for it ("everybody knows builtin types") implies that's exactly what you're expecting with this proposal.

However, there's an easy way around this: just let [spam] in your syntax mean  what Iterable[spam] means in MyPy's. If someone really needs to declare that they will only accept a list or whatever, that's the uncommon case, and can be written more verbosely. And I don't see any reason why this can't be added on top of genericizing the ABCs a la MyPy.

Meanwhile, your tuple doesn't fit the same pattern as the others, because it's explicitly fixed-size and heterogeneous. And I think this is a good thing. And I think it's pretty close to what MyPy does with an expression list of types already; if not, it seems like what MyPy _should_ do. If I loop over a zip of a [str] and an [int], the loop variable is a (str, int), not a Tuple[str or int].

So, making it easier to specify generic builtins is a bad idea, but using builtins to make it easier to specify common types is a great idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140816/b07f98f3/attachment-0001.html>