mark florisson, 07.05.2012 19:13: > On 7 May 2012 18:06, Stefan Behnel <stefan...@behnel.de> wrote: >> mark florisson, 07.05.2012 18:18: >>> On 7 May 2012 17:16, mark florisson wrote: >>>> On 7 May 2012 17:12, Stefan Behnel wrote: >>>>> Dag Sverre Seljebotn, 07.05.2012 18:07: >>>>>> On 05/07/2012 06:04 PM, mark florisson wrote: >>>>>>> On 7 May 2012 12:10, Stefan Behnel wrote: >>>>>>>> BTW, is there a reason why we shouldn't allow a "not None" declaration >>>>>>>> for >>>>>>>> cdef functions? Obviously, the caller would have to do the check in >>>>>>>> that >>>>>>>> case. >>>>>>> >>>>>>> Why can't the callee just check it? If it's None, just raise an >>>>>>> exception like usual? >>>>>> >>>>>> It's just that there's a lot more potential for rather easy optimization >>>>>> if >>>>>> the caller does it. >>>>> >>>>> Exactly. The NoneCheckNode is easy to get rid of at any stage in the >>>>> pipeline, whereas a hard coded None check has a fixed cost at runtime. >>>> >>>> I see, yes. I expect a pointer comparison to be reasonably >>>> insignificant compared to function call overhead, but it would also >>>> reduce the code in the instruction cache. If you take the address of >>>> the function though, or if you declare it public in a pxd, you >>>> probably don't want to do that, as you still want to be safe when >>>> called from C. Could do the same trick as in the 'less annotations' >>>> CEP though, that would be nice. >>> >>> ... or you could document that 'not None' means the caller cannot pass >>> it in, but that would be weird as you could do it from Cython and get >>> an exception, but not from C :) That would be better specified in the >>> documentation of the function as its contract or whatever. >> >> "not None" on a cdef function means what all declarations on cdef functions >> mean: the caller is responsible for doing the appropriate type conversions >> and checks. >> >> If a function accepts an int32 and the caller puts a float32 on the stack, >> it's not the fault of the callee. The same applies to extension type >> arguments and None checks. > > Well, 'with gil' makes the callee do something.
There's two sides to this one. A "with gil" function can be called from nogil code, so, in a way, the "with gil" declaration is only a short hand for a "nogil" declaration with a "with gil" block inside of the function. It's also a historical artefact of the (long) time before we actually had "with gil" blocks, but it's convenient in that it saves a level of indention that would otherwise uselessly cover the whole function. > I would personally > expect not None to be enforced at least conceptually in the function > itself. As usual: in Python functions, yes, in C functions, no. Vitek's Python wrapper split was a good step into a better design here that reflects this separation of concerns. > In any case, I also think it's really not an important issue, > as it's likely pretty uncommon to call it from C. If it does break, it > will be easy enough to figure out (unless you accidentally corrupt > your memory :) So either solution would be fine with me. Good. Stefan _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
