Can you add your example to the issue?
https://github.com/ambv/typehinting/issues/107
We're trying to finish up PEP 484 in the next few days (wait for an
announcement :-) and we just don't have time for every use case; but over
the course of 3.5 we will be adding features that are considered usefu
18.05.2015, 18:05, Guido van Rossum kirjoitti:
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm
mailto:alex.gronh...@nextday.fi>> wrote:
18.05.2015, 02:50, Guido van Rossum kirjoitti:
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
mailto:alex.gronh...@nextday.fi>> wrote:
On Mon, May 18, 2015 at 12:14 AM, Alex Grönholm
wrote:
>
>
> 18.05.2015, 02:50, Guido van Rossum kirjoitti:
>
> On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
> wrote:
>
>> Looking at PEP 484, I came up with two use cases that I felt were not
>> catered for:
>>
>>1. Specifying that a param
18.05.2015, 02:50, Guido van Rossum kirjoitti:
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
mailto:alex.gronh...@nextday.fi>> wrote:
Looking at PEP 484, I came up with two use cases that I felt were
not catered for:
1. Specifying that a parameter should be a subclass of anothe
> > Looking at PEP 484, I came up with two use cases that I felt were not
> > catered for:
> >
> >1. Specifying that a parameter should be a subclass of another
> >(example: Type[dict] would match dict or OrderedDict; plain "Type"
would
> >equal "type" from builtins)
> >
> >
> I don't
On Sun, May 17, 2015 at 3:07 PM, Alex Grönholm
wrote:
> Looking at PEP 484, I came up with two use cases that I felt were not
> catered for:
>
>1. Specifying that a parameter should be a subclass of another
>(example: Type[dict] would match dict or OrderedDict; plain "Type" would
>eq
Looking at PEP 484, I came up with two use cases that I felt were not
catered for:
1. Specifying that a parameter should be a subclass of another
(example: Type[dict] would match dict or OrderedDict; plain "Type"
would equal "type" from builtins)
2. Specifying that a callable should take a
