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

Dag Sverre Seljebotn d.s.seljebotn at astro.uio.no
Mon May 7 12:40:50 CEST 2012

[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?).


More information about the cython-devel mailing list