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

Stefan Behnel stefan_ml at behnel.de
Sat Jan 17 10:58:01 CET 2015


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".

Stefan




More information about the Python-ideas mailing list