<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Well the whole point is not to have to figure out how to implement that right now.<br></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 6:45 PM, Random832 <span dir="ltr"><<a href="mailto:random832@fastmail.com" target="_blank">random832@fastmail.com</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>> writes:<br>
> The proposal is to allow this to be written as follows in<br>
> implementation (non-stub) modules:<br>
><br>
> class Foo(Generic[T]):<br>
> @overload<br>
> def __getitem__(self, i: int) -> T: ...<br>
> @overload<br>
> def __getitem__(self, s: slice) -> Foo[T]: ...<br>
> def __getitem__(self, x):<br>
> <actual implementation goes here><br>
><br>
> The actual implementation must be last, so at run time it will<br>
> override the definition.<br></span></blockquote></div></div></blockquote><div><br></div><div>I think this <i>could</i> be fine. It is certainly readable. And, as is already possible in .pyi files, more accurately expressive than the Union which doesn't imply a parameter type to return value type relationship.</div><div><br></div><div>What would it Foo.__getitem__.__annotations__ contain in this situation?</div><div>It'd unfortunately be an empty dict if implemented in the most trivial fashion rather than a dict containing your Unions... Do we care?</div><div><br></div><div><div>Note that it would also slow down module import time as the code for each of the earlier ... definitions with annotation structures and @overload decorator calls is executed, needlessly creating objects and structures that are immediately discarded upon each subsequent definition.</div></div><div><br></div><div>-gps</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
</span>How about this to allow overloads to have actual implementations?<br>
<br>
@overloaded<br>
def __getitem__(self, x):<br>
    <default implementation, if none of the overloads matched><br>
<br>
@overloaded returns a function which will check the types against the<br>
overloads (or anyway any overloads that have actual implementations),<br>
call them returning the result if applicable, otherwise call the<br>
original function.<br>
<br>
Some magic with help() would improve usability, too - it could print all<br>
the overloads and their docstrings.  Maybe even @overload('__getitem__')<br>
def __get_int(self, i: int), to make it so order doesn't matter.<br>
<br>
That just leaves the question of how's this all gonna work with<br>
subclasses.<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</blockquote></div></div><div class="gmail_extra"><br><br clear="all"><br>-- <br><div>--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/greg%40krypto.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br>
</blockquote></div></div>