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

[Dag Sverre Seljebotn]

[moving to dev list]

On 05/07/2012 11:17 AM, Stefan Behnel wrote:
> Dag Sverre Seljebotn, 07.05.2012 10:44:
>> On 05/07/2012 07:48 AM, Stefan Behnel wrote:
>>> shaunc, 07.05.2012 07:13:
>>>> The following code:
>>>>
>>>> cdef int foo( double[:] bar ) nogil:
>>>>       return bar is None
>>>>
>>>> causes: "Converting to Python object not allowed without gil"
>>>>
>>>> However, I was under the impression that: "When comparing a value with
>>>> None,
>>>> keep in mind that, if x is a Python object, x is None and x is not None are
>>>> very efficient because they translate directly to C pointer comparisons,"
>>>>
>>>> I guess the problem is that the memoryview is not a python object --
>>>> indeed, this compiles in the form:
>>>>
>>>> cdef int foo( object bar ) nogil:
>>>>
>>>>       return bar is None
>>>>
>>>> But this is a bit counterintuitive... do I need to do "with gil" to check
>>>> if a memoryview is None? And in a nogil function, I'm not necessarily
>>>> guaranteed that I don't have the gil -- what is the best way ensure I have
>>>> the gil? (Is there a "secret system call" or should I use a try block?)
>>>>
>>>> It would seem more appropriate (IMHO, of course :)) to allow "bar is None"
>>>> also when bar is a memoryview....
>>>
>>> I wonder why a memory view should be allowed to be None in the first place.
>>> Buffer arguments aren't (because they get unpacked on entry), so why should
>>> memory views?
>>
>> ? At least when I implemented it, buffers get unpacked but the case of a
>> None buffer is treated specially, and you're fully allowed (and segfault if
>> you [] it).
>
> Hmm, ok, maybe I just got confused by the code then.
>
> I think the docs should state that buffer arguments are best used together
> with the "not None" declaration then.

I use them with "=None" default values all the time... then do a
None-check manually.

It's really no different from cdef classes.

> And I remember that we wanted to change the default settings for extension
> type arguments from "or None" to "not None" years ago but never actually
> did it.

I remember that there was such a debate, but I certainly don't remember
that this was the conclusion :-) I didn't agree with that view then and
I don't now. I don't remember what Robert's view was...

As far as I can remember (which might be biased towards my personal
view), the conclusion was that we left the current semantics in place,
relying on better control flow analysis to make None-checks cheaper, and
when those are cheap enough, make the nonecheck directive default to
True (Java is sort of prior art that this can indeed be done?).

Dag