<br><br><div class="gmail_quote">On Sat Aug 16 2014 at 10:38:34 AM Andrew Barnert <abarnert@yahoo.com.dmarc.invalid> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto"><div>On Aug 16, 2014, at 6:00, Dave Halter <<a href="mailto:davidhalter88@gmail.com" target="_blank">davidhalter88@gmail.com</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div dir="ltr">
<div><div><b>Appendix (My Proposal)</b></div><div><div class="gmail_extra"><br></div><div class="gmail_extra">
My proposal (as discussed and evolved with a few good people at EuroPython) for containers would look something like this:</div><div class="gmail_extra"><br></div><div class="gmail_extra">  Â  def foo(index: int, x: [float], y: {int: str}) -> (float, str):</div>


<div class="gmail_extra">  Â  Â  Â  return x[index], y[index]</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">- 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)`.</div>

- 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.<div class="gmail_extra">

- Argument clinic could use the same. The standard library quite often doesn't accept abstract data types, btw. </div><div class="gmail_extra">- It's what people sometimes use in docstrings: ``@rtype: (float, str)`` or ``:rtype: (float, str)``.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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. </div>
</div></div></div></div></blockquote><div><br></div></div><div dir="auto"><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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].</div>
<div><br></div><div>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.</div></div></blockquote><div><br></div><div>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. </div>
</div>