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

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Mon May 7 18:22:38 CEST 2012


On 05/07/2012 06:18 PM, mark florisson wrote:
> On 7 May 2012 17:16, mark florisson<markflorisson88 at gmail.com>  wrote:
>> On 7 May 2012 17:12, Stefan Behnel<stefan_ml at behnel.de>  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.
>>>
>>> Stefan
>>> _______________________________________________
>>> cython-devel mailing list
>>> cython-devel at python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>> 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.

We're going to need a "Cython ABI" at some point anyway. "Caller checks 
for None" goes in the ABI docs.

Dag


More information about the cython-devel mailing list