[Cython] CEP 507/513
Robert Bradshaw
robertwb at math.washington.edu
Sun Apr 13 04:12:48 CEST 2008
I am starting an email thread about these two Cython Enhancement
Proposals because I think this is a better forum than embedding lots
of comments in the wiki page.
The original proposal was that some Python objects (e.g. list, tuple,
dict, str) would be known by the compiler and optimized accordingly
(e.g. using the appropriate macros for indexing). One thing that is
radical about this proposal (and why a pxd file wouldn't suffice) is
that something declared "cdef list" would have to be *exactly* a
list, not a subclass of list. In this case I think it is worth it
because there are enormous gains to be made and 99% of Python lists
are actually just lists. These would be exactly like C types which
have no hierarchy.
In general type declarations of Python objects should accept
subclasses of that object. Great pains are taken to make subclassing
work well for extension types (vtables for cdef methods, all the
magic that makes cpdef methods and optional arguments work). This is
in fact one of the main tenants of object oriented programing. This
is why statements like
> cdef T a = x
>
> * With the exception of object, subtype instances can not be
> assigned. x has to be exactly of the type T. Some extension syntax
> (descendants(T) or similar) can be added later, but it doesn't seem
> like a normal usecase.
make me quite hesitant.
In the question of being allowed to do
> cdef T a = x
for T a python class (not cimported, and not even necessarily a type)
I am not sure this is a good thing. The *only* reason we declare
types for python objects is to be able to do static binding. If T is
not statically declared, then there is no advantage (other than
perhaps type checking which can be done anyways). With no advantages,
and it goes against the "duck typing" philosophy of Python (though
one can always manually check the type if one needs it), I'm not
convinced that we want to go this route.
I would like more feedback on this from the general community before
rejecting it outright however.
- Robert
More information about the Cython-dev
mailing list