[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
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
