Stefan Behnel wrote: > But Pyrex types are already optimised in a couple of ways.
Yes, but those things are all internal to the type itself. When you call a method or access an attribute, you expect these things to be handled in a way that depends on the type. But isinstance() isn't like that -- it's a function that operates from outside the object. You don't expect functions like that to behave differently depending on the type, unless it's delegating to some method, such as __len__. That's not the case here -- it's not calling any kind of type-specific class-testing method, it's doing everything from outside. > Taking this a bit out of context, this is exactly my point. If you don't know > much about the C-API, you a) won't notice the difference and b) will expect > isinstance(obj, ExtType) to make sure that the type has the expected type > struct. Perhaps I can put some context back in here. The places where this matters are inside special methods such as __add__. These methods are already wildly different from their Python counterparts, so you have to know you're in a different land and that different rules apply. Basically you have to RTM (where M is the Pyrex manual, not the Python/C API manual). Actually, it's just occurred to me that using isinstance where you should have used typecheck might not be as dangerous a problem as I thought. The reason is that in order to access any C attributes, you still need to cast it to the appropriate type, and Pyrex will generate a strict type test when you do that. So the worst that can happen is that you get a TypeError from a slightly unexpected place. -- Greg _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
