Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

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 append).

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.types contains names that always refers to C types. So doing from cython.types import int will mean that "int(x)" will start meaning casting to C int rather than creating a Python int object.
  • Explicitly using __builtin__.int means to use the Python object, so cdef __builtin__.int x means that "x" is a full Python "int" object (for possible optimizations/early binding that cdef object x can't provide).
  • For plain "int", keep the current behaviour of different meaning in type context and runtime context.

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.

Something went wrong with that request. Please try again.