Showing content from http://mail.python.org/pipermail/python-dev/attachments/20151024/92d20aec/attachment.html below:
<div dir="ltr">I've thought this over and I don't think it's worth it. We need to wait for a working proposal for multi-dispatch first. Otherwise we'll just end up having to support this interim syntax *and* whatever the new multi-dispatch is. Keeping @overload restricted to stub files makes it much more tractable.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 10:51 AM, Guido van Rossum <span dir="ltr"><<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith <span dir="ltr"><<a href="mailto:greg@krypto.org" target="_blank">greg@krypto.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><br><div class="gmail_quote"><span><div dir="ltr">On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">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></span><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></div></blockquote><div><br></div></span><div>Right, which is how this got started.<br>Â <br></div><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div></span><div>Initially it would indeed be {}. Once we have a true multi-dispatch PEP we can iterate, both on how to spell it (perhaps the final __getitem__ needs an @overload as well) and on what happens in the annotations (or at least, what typing.get_type_hints() returns).<br><br></div><div>We could also wait for a multidispatch PEP to land -- but I'm worried that we'll be waiting past 3.6.<br><br></div><div>Then again I don't see how true multidispatch would be able to deal with the syntax proposed here -- you need some kind of decorator on the fallback implementation.<br></div><span class=""><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><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></div></blockquote><div><br></div></span><div>Yes, but I don't think this is going to make a noticeable difference.<br></div><div>Â </div></div><span class=""><br>-- <br><div>--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</span></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4