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

[Robert Bradshaw]

On Mon, May 7, 2012 at 3:40 AM, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> [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?).

Yes, that was exactly my point of view.

- Robert