[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