Robert Bradshaw, 18.08.2010 06:27: > Given that this only impacts cdef classes, what contracts are we > making about the availability of unbound special methods? For example, > we're OK with not exposing __long__. I'm leaning towards a cdef class > being as fast as possible, while a normal class is 100% python > semantics.
This contradicts our often stated goal that it should be easy to move code from Python to Cython and that Cython code should mimic Python semantics as closely as possible. I find this a very valuable goal. It also poses problems for classes that must be cdef classes because they wrap C values, as in pretty much all wrapper code. The simple fact that it's a cdef class doesn't imply that a user wants Python visible semantics that diverge from Python and thus impact the users of the class. If we can't help it, well, then that's how it must work. But we can clearly avoid the problem in this case. > Perhaps we should control this with a flag. I'm not a big fan at all of changing behaviour with flags, but I'm strictly against doing it in cases where the resulting behaviour is not obvious. It's absolutely not obvious to me that a flag to make a call to a regular Python special method faster makes that method unavailable from Python code. Such an impact is too easy to get missed by tests. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
