[Python-ideas] Proposal: Use mypy syntax for function annotations

Nick Coghlan ncoghlan at gmail.com
Thu Aug 21 18:15:53 CEST 2014


On 21 August 2014 23:23, Antoine Pitrou <antoine at python.org> wrote:
> Le 20/08/2014 23:28, Jim Baker a écrit :
>>
>>
>> Mypy’s approach to parameterizing types using slice
>> notation/|__getitem__| is a rather neat hack, given how it does not
>>
>> require any new notation, matches rather similar syntax in languages
>> like Scala and Haskell, and can be readily added to existing types,
>> whether builtins like |list|, collections like |deque|, or ABC
>> collection types like |Iterator| and|Sequence|. Adding such
>>
>> parameterization support to builtin/stdlib types is a compelling reason
>> for including in 3.5. An enthusiastic +1!
>
>
> I'm -1 on using __getitem__ for parametering types. It is indeed a hack and
> its limitations will bite us harshly when wanting to refine the type
> descriptions (for example to describe a constraint on a collection's size).

Given:

    Sequence[Number]
    Sequence[Number|None]

There's still at least three options for extending the syntax even further:

    Sequence[Number](EXPR)
    Sequence[Number:EXPR]
    Sequence[Number,EXPR]

You'd probably want to use strings at that point, for the same reasons
PyContracts does. For example:

    Number,"N>0" # Positive number
    Sequence[Number,"N>0"] # Sequence of positive numbers
    Sequence[Number],"N>0" # Non-empty sequence

I doubt we'll ever get to that point, though. Type hinting and runtime
assertions aren't the same thing.

>> One last thing: let’s not add |List|, |TList|, etc. Just use |list| and
>>
>> other existing types to generate new types.
>
> I'm -1 on that, for exactly the same reason as above.

I'm also -1, on the grounds that concrete types and ABCs are
different, and I think type hinting should be heavily biased towards
ABCs.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list