<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 26, 2014 at 12:00 PM, Eugene Toder <span dir="ltr"><<a href="mailto:eltoder@gmail.com" target="_blank">eltoder@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Dec 25, 2014 at 10:41 PM, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></span>[...]<span class=""><br>
> Eek. That sounds like a bad idea -- copy.copy() uses introspection and I<br>
> don't think there's much hope to be able to spell its type.<br>
</span>Does it really use more introspection than your space_for() function? Naively,<br>
copy is implemented like:<br>
<br>
def copy(obj):<br>
    if isinstance(obj, int): return obj<br>
    if isinstance(obj, list): return list(obj)<br>
    ...<br>
    return obj.__copy__()<br>
<br>
This does not seem very hard to type.</blockquote><div><br></div><div>Well, it copies most class instances by just copying the __dict__. And it recognizes a bunch of other protocols (__copy__ and most pickling interfaces).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are much simpler examples, though:<br>
<br>
a) Keys of Dict and elements of Set must be Hashable,<br>
b) To use list.index() list elements must be Comparable,<br>
c) Arguments to min() and max() must be Ordered,<br>
d) Arguments to sum() must be Addable.<br>
<br>
So it's not uncommon to have generic functions that need restrictions on type<br>
variables.<span class=""><br></span></blockquote><div><br></div><div>I think you are still trying to design a type system that can express all constraints exactly. In practice I doubt if any of the examples you mention here will help catch many bugs in actual Python code; a type checker that is blissfully unaware of these requirements will still be tremendously useful. (I guess this is the point of gradual typing.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> That sounds like an artificial requirement on the implementation designed to<br>
> help the type checker.<br>
</span>Perhaps I'm not explaining this right. The requirement is not for the type<br>
checker, it is to be able to implement the function. As you pointed out<br>
earlier, without any requirements on the type the function will not be able to<br>
produce the value.<span class=""><br></span></blockquote><div><br></div><div>Yeah, but my counter is that Python users today don't write classes like that, and I don't want them to have to change their habits.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> Peter Norvig mentioned that the subtleties of co/contra-variance of generic<br>
> types in Java were too complex for his daughter, and also reminded me that<br>
> Josh Bloch has said somewhere that he believed they made it too complex.<br>
</span>IIUC the context for both statements is specifically the call site annotations<br>
of variance, i.e. <?T extends C> and <?T super C>. Though you can also quote<br>
Gilad Bracha, who declared that variance is too complicated notion for<br>
programmers to understand, and made all generics in Dart covariant. This<br>
was also the case in Beta, whose authors denounced invariance and<br>
contravariance, as coming from people "with type-checking background" :-)<br></blockquote><div><br></div><div>I'm not sure I understand why you think that is funny. I think they all have a point.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> But I can see a serious downside as well. There will likely be multiple<br>
> tools that have to be able to read the type hinting annotations, e.g. IDEs<br>
> may want to use the type hints (possibly from stub files) for code<br>
> completion purposes. Also someone might want to write a decorator that<br>
> extracts the annotations and asserts that arguments match at run time. The<br>
> more handy shorthands we invent, the more complex all such tools will have<br>
> to be.<br>
</span>I think if these tools cannot use functions from the typing module they will<br>
have bigger problems than shorthands. And the number of shorthands is pretty<br>
limited -- there are only as many literals in Python.<span class=""><br></span></blockquote><div><br></div><div>I think there are at least three separate use cases (note that none are part of the proposal -- the proposal just enables a single notation to be used for all three):<br><br></div><div>(1) Full type checkers like mypy. These have to parse everything without ever running it, so they cannot use the typing module's primitives. They may also have to parse stuff in comments (there are several places where mypy needs a little help and the best place to put it is often in a #type: comment), which rules out Python's ast module.<br><br></div><div>(2) Things that use runtime introspection, e.g. decorators that try to enforce run time correctness. These can use the typing module's primitives. I wish we could just always have (generic) type objects in the annotations, so they could just look up the annotation and then use isinstance(), but I fear that forward refs will spoil that simplicity anyway.<br><br></div><div>(3) IDEs. These typically need to be able to parse code that contains errors. So they end up having their own, more forgiving parser.<br></div><div><br></div><div>That's enough distinct cases to make me want to compromise towards a slightly more verbose syntax that requires less special handling. (I am also compromising because I don't want to change CPython's parser and I want to be able to backport typing.py to Python 3.4 and perhaps even 3.3.)<br></div><div><br></div></div>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido">python.org/~guido</a>)</div>
</div></div>