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

Stefan Behnel stefan_ml at behnel.de
Tue May 8 08:12:18 CEST 2012


mark florisson, 07.05.2012 19:13:
> On 7 May 2012 18:06, Stefan Behnel <stefan_ml at 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


More information about the cython-devel mailing list