Andrew Straw wrote: > Robert Bradshaw wrote: >> On Aug 21, 2008, at 5:50 AM, Andrew Straw wrote: >> >> >>> Robert Bradshaw wrote: >>> >>> >>>>>> Dag Sverre Seljebotn wrote: >>>>>> >>>>>> >>>>>>> Andrew Straw wrote: >>>>>>> >>>>>> great aspect of Cython, IMO, is that it makes Python/C bridges >>>>>> easier, >>>>>> not to adhere to the minimum standards specified by a PEP. Thus >>>>>> a small >>>>>> amount of additional error checking seems OK to me. Also, as >>>>>> another >>>>>> >>>>>> >>>>> Well, in this case, the error check should be done by inserting some >>>>> code automatically in the definition of __getbuffer__, so that >>>>> Python 3 >>>>> consumers also get advantage of it, and so that we don't second >>>>> guess >>>>> how good non-Cython implementations are. So the check is still >>>>> inserted >>>>> in the wrong place. >>>>> >>>> I agree, this is the right place to put the check. And I think it >>>> is very >>>> worth the (relatively small) overhead to insert a check here. >>>> >>> Just to be clear (re-reading this bit after Robert's response makes me >>> realize I'm confused about your meaning): what do you mean by "the >>> definition of __getbuffer__" -- the C Python implementation of >>> PyObject_GetBuffer()? I thought my patch did affect the (Cython) >>> definition of __getbuffer__. >>> >> >> What I was thinking is that when a user writes a __getbuffer__ >> method, a check is inserted at the end of their method before it >> returns to make sure all is sane. >> >> > (I'm actually totally content to let this particular issue die now, but > I'm still curious about the Cython internals, so if you'll humour me...)
Definitely! > OK, so there'd be part of the Cython compiler that checked if the name > of the current method was "__getbuffer__" and if the class was an > extension ctypedef, upon which it would insert some check before the > method returned? I don't know the internals of Cython enough to know > whether that would be a gratuitous hack or reasonable behavior... But if > you point me in the right direction, I'll have a look. Pick one: 1. Stick a transform in PostParseTransforms.py which intercepts FuncDefNodes, and if the name matches (and they are a method of a cdef class) you replace the body with a TryFinallyNode where the try-part gets the old body and the finally part gets an IfStatNode which has a condition node which checks things and a RaiseStatNode to raise the exception. 2. Have a look at Nodes.FuncDefNode.generate_function_definition and insert a check for self.name == "__getbuffer__" (and somehow a check that you are in a cdef class, not sure, well, at least "self.scope.parent_scope" should be a cdef class scope, for scopes see Symtab.py), and if it matches, then simply output the C code at the right place (after the label that is jumped to for return statements). 2 is much quicker so that is likely what you'd like to do, unless you prefer the coding style of 1. >>> Also, wouldn't Cython emit the same C code >>> for Python 3? >>> >> >> Python 3 actually has a buffer protocol, so we don't need to emulate it. >> > No need to emulate the buffer protocol, but there is a need for > extension types defined in Cython to have something that goes from a > __getbuffer__ Cython method to a Python C API call. I can't see how that > would disappear. That's what I mean. Not sure what you are asking but here's the whole thing: - __getbuffer__ is output as a normal C function - if you are compiling in Python 3, the address of it is put in the getbuffer slot of the type - if you are compiling in Python 2, it is called in our fake __Pyx_GetBuffer implementation (which under Python 3 is simply #define-ed to PyObject_GetBuffer). Then, when we need a buffer, __Pyx_GetBuffer is called,. What you modified was __Pyx_GetBuffer_$DTYPE, which is code used by the buffer consumer, not the buffer exporter. The difference isn't that big but putting the test in __getbuffer__ means that non-Cython Python 3 code also gets benefit of the test, and it is where it logically belongs as then the PEP isn't "violated and then corrected", rather you get help in order to not violate it in the first place. If you do this I'm +1. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
