Clone this wiki locally
CEP 507 - Compile-time binding of Python types
Currently, Cython does runtime checking for certain types (e.g. lists and tuples) for things like fast indexing. This speeds things up immensely. However, sometimes it would be nice to declare a type so the fast methods would always be used. With type inference, this could be especially useful (e.g.
 would know it's a list which would be propigated when one calls
I (robertwb) propose that
cdef list L = x
be the syntax, and it would raise a type error if x were not exactly a list (or None?). Subclasses would be disallowed (one could not safely access their members through non-generic methods) and conversion would not happen (it could be prohibitively expensive and is easy to do explicitly).
How to name Python ints/longs is an interesting question.
Avoiding name collisions
- One proposal:
- The module
cython.typescontains names that always refers to C types. So doing
from cython.types import intwill mean that "int(x)" will start meaning casting to C int rather than creating a Python int object.
- Explicitly using
__builtin__.intmeans to use the Python object, so
cdef __builtin__.int xmeans that "x" is a full Python "int" object (for possible optimizations/early binding that
cdef object xcan't provide).
- For plain "int", keep the current behaviour of different meaning in type context and runtime context.
- The module
Extension to all Python types
A proposal for extending this to all Python types can be found here. It didn't get support due to the fact that it requires syntax that completely contradicts all common OO principles which will be very confusing. It can be altered to support OO principles, however it then doesn't bring any performance benefits and seems to be too much trouble only for the sake of some consistency in the language that nobody will use.