All these overloads makes the code hard to read.
The whole idea of 'i have to know which decorator
got called before the other one' is a smell that
you have too many decorators.
This whole idea reeks 'i can be very, very clever here'.
Laura
___
Python-
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 tractabl
On Fri, Oct 23, 2015 at 8:38 AM, Nick Coghlan wrote:
> On 22 October 2015 at 19:51, Guido van Rossum wrote:
> > On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith
> wrote:
> >> What would it Foo.__getitem__.__annotations__ contain in this situation?
> >> It'd unfortunately be an empty dict if im
On 22 October 2015 at 19:51, Guido van Rossum wrote:
> On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith wrote:
>> 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 conta
On Thu, Oct 22, 2015 at 2:21 AM, Gregory P. Smith wrote:
>
>
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum 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
>> wrote:
>>
>>> Guido van Rossum w
On 22 October 2015 at 10:21, Gregory P. Smith wrote:
> On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum 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 wrote:
>>>
>>> Guido van Rossum writes:
>>>
On Wed, Oct 21, 2015 at 6:51 PM Guido van Rossum 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 wrote:
>
>> Guido van Rossum writes:
>> > The proposal is to allow this to be written as follows in
>> >
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 wrote:
> Guido van Rossum writes:
> > The proposal is to allow this to be written as follows in
> > implementation (non-stub) modules:
> >
> > class Foo(Generic[T]):
> >
Guido van Rossum 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):
>
>
>
PEP 484 (Type Hinting) currently disallows @overload outside stub files.
The hope was that a PEP for multi-dispatch would emerge, but that's been
slow coming.
Meanwhile, over in https://github.com/ambv/typehinting/issues/72 a proposal
has emerged to allow @overload in regular modules, as long as i
10 matches
Mail list logo
