[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