[Cython] CEP 507/513

[Robert Bradshaw]

On Apr 13, 2008, at 6:36 AM, Dag Sverre Seljebotn wrote:
> 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?


The did seem very related, at least in my initial reading, and the  
whole mixin idea seemed to rely on declaring non-cdef'ed types.

Reading CEP 513 again, I think the whole thing boils down to two things:

1) Automatic cimport on import, under certain conditions (e.g. if a  
corresponding .pxd file is found in the internal cython path)
2) Function overloading

The only reason Python didn't have (2) is because it had no way of  
declaring types, and hence distinguishing between overloaded  
functions (well, perhaps parameter count, but that's not very  
compelling)). This will change in Python 3000 http://www.python.org/ 
dev/peps/pep-3124/ , and I think we should backport that to Cython  
(maybe not the whole PEP, but overloadable functions using @overload  
or type signatures. In math.pxd one would declare sqrt for several  
native types, and the object one would be the fallback. Def vs. cdef  
could be interchangeable at this level.

Taking external types into consideration (see http:// 
www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/ 
extension_types.html#ExternalExtTypes ), I think the rest of the CEP  
could be greatly simplified. It is possible I missed something not  
covered by (1) and (2), but I believe this is the gist of the proposal.

- Robert