On 22 October 2015 at 10:21, Gregory P. Smith <g...@krypto.org> wrote: > On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum <gu...@python.org> wrote: >> >> Well the whole point is not to have to figure out how to implement that >> right now. >> >> On Wed, Oct 21, 2015 at 6:45 PM, Random832 <random...@fastmail.com> wrote: >>> >>> Guido van Rossum <gu...@python.org> writes: >>> > The proposal is to allow this to be written as follows in >>> > implementation (non-stub) modules: >>> > >>> > class Foo(Generic[T]): >>> > @overload >>> > def __getitem__(self, i: int) -> T: ... >>> > @overload >>> > def __getitem__(self, s: slice) -> Foo[T]: ... >>> > def __getitem__(self, x): >>> > <actual implementation goes here> >>> > >>> > The actual implementation must be last, so at run time it will >>> > override the definition. > > > I think this could 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. > > What would it Foo.__getitem__.__annotations__ contain in this situation? > It'd unfortunately be an empty dict if implemented in the most trivial > fashion rather than a dict containing your Unions... Do we care? > > 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.
Is the idea that in future the "..." dummy declarations could be replaced by specialised implementations for the particular type combinations? If not, is there a risk that by grabbing the @overload decorator just for typing we lose the option of using the natural spelling for an actual multi-dspatch implementation? Paul _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
