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

[Brett Cannon]

On Sat Aug 16 2014 at 10:38:34 AM Andrew Barnert
<abarnert at yahoo.com.dmarc.invalid> wrote:

> 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.
>

The trick in all of this is making sure people instinctively know what the
builtin types represent in terms of an interface w/o necessarily
over-specifying. For instance, a list could be viewed as MutableSequence
when all that is really necessary is Sequence or Iterable. Just think of
those situations where a list or tuple both work as an argument; how do you
specify that without assuming mutability? It's tricky to figure out what a
proper assumption of what the built-ins represent should be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140816/0be2105b/attachment.html>