[Python-ideas] PEP 484 (Type Hints) -- first draft round

[Stefan Behnel]

Stefan Behnel schrieb am 17.01.2015 um 10:58:
> Stefan Behnel schrieb am 17.01.2015 um 10:43:
>> Guido van Rossum schrieb am 16.01.2015 um 21:08:
>>> I don't know what to answer for Cython -- doesn't it have its own syntax
>>> for declaring C types? Or is it now also using annotations?
>>
>> It can, but it's optional. When I added support for it, I took care not to
>> enable it by default, so that it wouldn't accidentally interfere with other
>> usages of annotations.
>>
>> The current proposal seems less generous in this regard, and the way I see
>> it, the only gain from Cython's point of view is its very limited support
>> for container item type declarations and function signatures of callable
>> objects. Both are restricted to Python object types and even imply slightly
>> different semantics than Cython (I didn't see a notion of "exact types" as
>> opposed to "type or subtype").
>>
>> If there was at least a notion of "unknown types" that tools like static
>> type checkers MUST ignore (couldn't find that in the PEP either), then
>> Cython users could mix this with Cython's Python level type mapping through
>> the "cython" magic module, e.g. something like "cython.struct(x=cython.int,
>> y=cython.p_char)".
> 
> BTW, I think namespaces naturally fix this issue. If all of the proposed
> type system lives either in the builtin namespace or in the "typing"
> module, then annotations and type hints from any other module namespace
> MUST simply be ignored by tools that don't understand them, and are also
> easy to ignore. Then you could write "x: typing.List[cython.int]", and
> static type checkers could still validate that all input for "x" is a list
> (of some unknown item type), and Cython could enforce that anything coming
> out of such a list at runtime can coerce to a C "int".

https://github.com/ambv/typehinting/pull/44

Stefan