Stefan Behnel wrote: > Wouldn't special casing a type test for builtins and extension classes be > better here than adding new functions?
I'm not sure what you mean by that. There's no run-time distinction between a builtin class, an extension class implemented with Pyrex, or an extension class created some other way. They're all just types. I could make the Pyrex version of isinstance() behave differently, but then it wouldn't have quite the same semantics as it does in Python. That could be confusing, especially since you aren't guaranteed to be always getting the directly-called version. Rather than fiddle with the semantics, I felt it was better to provide different functions -- EIBTI and all that. They're not really new functions, anyway -- they're just exposing functions that are in the Python API, and they're the ones you would use if you were writing the extension module in C. > I mean, we already had that with getattr3(), where the right > thing to do would have been to fix builtin functions. That was a matter of pragmatism. I don't currently have any mechanism for dealing with a C function that can have more than one signature. I would have had to build a very special case into the guts of the compiler somewhere, which I didn't feel was worth doing just for that one function. So I did the next best thing and provided something that works, even if it's not ideal. I can always come back and do something else later. I think we're coming up against those philosophical differences again. Pyrex code is not Python code, and doesn't pretend to be. I try to make things compatible where reasonably possible, but it's not an overriding principle. > So if you added doctests > to your test modules (as we do for ours), you could still validate the > resulting source code for Pyrex, but we could both join forces and benefit > from a growing test suite. Okay, so you just want me to run the Cython tests as well. That shouldn't be too hard. Is there somewhere I can download them from? -- Greg _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
