[Cython] Fwd: Re: [cython-users] checking for "None" in nogil function

Stefan Behnel stefan_ml at behnel.de
Mon May 7 19:06:17 CEST 2012


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.

Stefan


More information about the cython-devel mailing list