On Tue, Aug 17, 2010 at 11:11 PM, Stefan Behnel <[email protected]> wrote: > 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.
Long term, I think it would be valuable to compile, where possible, users classes into "cpdef" classes that have exactly the same semantics of classes with the speed of cdef classses. > 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. This isn't a migration 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. I think this is analogous to the always_allow_keywords flag. We disallow certain rare usecases for the sake of a widespread performance increase. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
