[Cython] CEP 507/513

[Martin C. Martin]

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.

Best,
Martin

Robert Bradshaw wrote:
> 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
> 
> _______________________________________________
> Cython-dev mailing list
> Cython-dev at codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev