Sturla Molden, 13.01.2010 11:29: > Den 12. jan. 2010 kl. 15.44 skrev Stefan Behnel <[email protected]>: > >>> cdef Foo bar = Foo() >>> cdef inline Foo fastbar = bar >>> >>> bar.method() # through vtab >>> fastbar.method() # direct call >> >> Why would you want to control this from user code? > > Because I feel the common usecase for skipping the vtab indirection is > calling a method repeatedly from user code. > > This will not break Python semantics globally, but be a local > optimization when the user knows the type of an object.
I'm not so much worried about Python semantics here. Extension types are different anyway. My main concern is with the user knowing "the type of an object". The optimisation you enforce here is based on an explicit type that you ask Cython to use. It's not based on the actual type of the object. If anywhere in the evolution of the code base it happens that the object in question is replaced with a subtype, the code above will break without warning and potentially in a subtle, non-obvious way. The only way to make this safe would be to enforce exact type checks on assignments to a "cdef inline" variable. That breaks other common code semantics, and it also wouldn't work for the case where a basetype defines a method that is *not* overridden by subtypes. But it would at least raise an exception if the code is known to be incorrect. Given that such a restriction would be required, I fail to see a real advantage over a 'final' class. > Another way of defining this could be by inheritance. For example: > > cdef class FastFoo(Foo, cython.finalobject): > pass > > cdef Foo bar = Foo() > cdef FastFoo fastbar = <FastFoo> bar That can't work because Foo isn't a FastFoo type. If we add a 'final' modifier to classes, a decorator is the only sensible syntax, IMHO. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
