Hi, Lisandro Dalcin wrote: > 1) Change the macros to true functions. We already need to emit > functions, so a few more will not harm.
I'm still not convinced, but I won't object. Note that I don't accept your second proposed change as a reason to do this. > Declaring pointers to functions is > not usual, but IMHO it is a very valid user case. I'm just saying that it's not likely in this specific case. > Note that I'm > talking about users that for some rare reason want to access the > PySet_XXX API's directly in Cython codes (or perhaps in a header file > which is 'cdef extern from ..,' included). ... which they won't have to do very often as Cython does most of the work for them already. In an ideal Cython world, users won't have to call *any* Python C-API functions on builtin types directly - with the possible exception of the Check/CheckExact functions (although a parameter type declaration will take care of this most of the time) and the string processing functions. > 2) Add type checking to function arguments, following the actual > implementations in Python 2.5. Again, that would be a bit pointless > for Cython usage of PySet API, but I'm still tinking about direct > calls to those API's. >From my POV, they are plain legacy functions that are only there to enable code to run on close-to-be-abandoned Python versions. So it's nice to have them and they definitely help users in writing portable code that works efficiently on newer Python versions. The only reason I could see why this additional overhead might be of any good is compatibility with tests that require the same type error behaviour on different platforms. However, I find it highly unlikely (and unpythonic) that people actually write tests specifically for the set type. So, no, I don't see any real reason to do that. Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
