Hi, Greg Ewing wrote: > Stefan Behnel wrote: > >> Greg Ewing wrote: >> >>> There's no run-time >>> distinction between a builtin class, an extension class >>> implemented with Pyrex, or an extension class created some >>> other way. >> >> I didn't mean at runtime. The compiler knows how to distinguish them. > > Well, there's no compile-time distinction either, really. > They're all the same thing. Treating a type differently > depending on whether it was implemented using a Pyrex > extension class would be bizarre and confusing.
Why? If the docs stated "explicitly testing isinstance(obj, ExtType) for a Pyrex extension type will make sure it's really that specific type with the expected field structure", then that's just another Pyrex/Cython specific enhancement that deals with the grey area between Python and C, and that most (should I say all?) users would expect anyway when calling isinstance(). This does in no way interfere with Python semantics, as testing for (non-cdefed) Python types will not imply a specific struct layout anyway. Make it a feature: tell people that they can assert the C type structure by calling isinstance(obj, MyExtType) explicitly, and that all other calls will use the normal Python semantics. Then, you could still use the following to do a non-explicit test: >> allowed_type = ExtType >> print isinstance(obj, allowed_type) # Python semantics This could even become an example in the docs, right next to the paragraph that explains the lack of "security" in the Python semantics. > I'm not going to be changing > my own test setup, so you're not going to be able to share > any new tests that I add without converting them to your > format. Ok, then we'll continue to do that. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
