[Cython] CEP 507/513

Dag Sverre Seljebotn dagss at student.matnat.uio.no
Sun Apr 13 15:36:49 CEST 2008


Martin C. Martin wrote:
> I too would be worried about changing the semantics of cdef T a = x. 
> But what about:
>
> cdef T a = x
> assert a.__class__ == T
>
> This makes it valid Python, which pins down the type of "a" exactly.  
> In fact, at this point you don't even need the "cdef T".
>
> It's slightly ugly, but with luck, that will discourage people from 
> premature optimization.
It's still dangerous:

a.myfunc = myoverride
assert a.__class__ == T
a.myfunc()

(On the subject of optimizations, one could also augment the CEP by 
having the notation "exactly(MyClass)" mean "early-bind all calls and I 
don't care about the consequences". Using "exactly(list)" would then 
mean that builtins wouldn't need to be a special-case either. But I'm 
fine with "list" being a special-case here.)

But at any rate, the point of the CEP was to have more consistency in 
Cython syntax, not necesarrily adding optimizations.

Robert makes a very good case (and has fully convinced me) for needing 
to support descendants being assigned (that not allowing that wasn't one 
of my brightest ideas). But independtly of this, it looks like C types, 
Python builtins, and Python extension types declared in pxd files are 
going to be supported. Simply allowing Python types as well simply makes 
it more consistent, even if it isn't that useful...

On the other hand, if it doesn't have a useful features, there 
definitely is a case for not bothering to implement it (well, it is 
useful for function overloading, but then again function overloading is 
less useful for Python objects :-) ). So I really wouldn't mind if this 
is rejected.

CEP 513 should be independent of this though?

-- 
Dag Sverre



More information about the Cython-dev mailing list