Hi, Greg Ewing wrote: > But C types are Python types too. There's no way > of reading the programmer's mind to find out whether > he's thinking of his extension type as a C type or > a Python type when he passes it to isinstance().
But Pyrex types are already optimised in a couple of ways. If you add a struct field, Pyrex will not use Python calls to access it but plain C calls. If you assign it to a variable, Pyrex will not look it up in the module dict. However, if you test its type, you expect the user to assume that Pyrex does not handle this its own way? I think most users will not agree with you here, and I feel comfortable saying so from the (although unrelated) feedback we get on the mailing list. At least Cython users expect optimised code that special cases common use patterns internally (such as "for ... in range()"), and they are surprised when they find that Cython/Pyrex gives them normal Python semantics in a "sub-optimal" way. > Another consideration is that while I try to make > it so that you don't need to know about the C > API in order to use Pyrex, I also want to make it > so that it seems natural to someone who *does* > know something about the C API. 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. However, if you know about the C-API and about the possible problems with isinstance() and PyObject_IsInstance(), you will either write the type check in an explicit C-API call or check the Pyrex/Cython docs for an easy way to do it for you, and then find the section on the semantics difference between Python and Pyrex here. In this case, you will most likely appreciate the fact that isinstance() has semantics in Pyrex that make sure isinstance(obj, ExtType) will give you the expected struct, and that you can easily get back the original Python semantics by not testing for the extension type explicitly. There is only one case where things are unexpected, which is if you rely on isinstance() being overridable by type.__class__. In this case, your code will fail and you will have to debug it - but only if you have written it under the expectation that extension types behave exactly like Python types. And I think that is a very unlikely expectation to have because users who found their path all the way through the language docs to figure out how to write an extension type will already have lost this expectation. For me, that's not the path of highest Python language compatibility, but it's the clear path of least surprises - as long as it's documented. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
