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...)
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. It does seem like the idea of a "training wheels" mode for Cython could be pretty useful -- a few of the other threads are mentioning various ideas, and it would probably make development of Cython code easier if there was a safe(r) but slower mode and a as fast as possible mode. >> 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. -Andrew _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
