On Mon, May 7, 2012 at 3:40 AM, Dag Sverre Seljebotn <d.s.seljeb...@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 _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
