@cython.cfunc compat with nogil declaration?

[Brock Mendel]

It looks like `nogil` does not play nicely with @cython.cfunc and related decorators.  Is this intentional?  Example:

This works:

cdef inline bint is_string_object(object obj) nogil:

    return 0

This raises Cython.Compiler.Errors.CompileError: Expected '(', found 'bint'

@cython.cfunc

def inline bint is_string_object(object obj) nogil:

    return 0

Same thing if `inline` and/or `bint` are moved into decorators.  AFAICT @cython.wraparound and @cython.boundscheck work OK.

[Stefan Behnel]

Brock Mendel schrieb am 22.09.2017 um 03:49:
> It looks like `nogil` does not play nicely with @cython.cfunc and related
> decorators. Is this intentional? Example:
>
> This works:
>
> cdef inline bint is_string_object(object obj) nogil:
> return 0
>
> This raises Cython.Compiler.Errors.CompileError: Expected '(', found 'bint'
>
> @cython.cfunc
> def inline bint is_string_object(object obj) nogil:
> return 0

That's because you are defining a "def" function here, i.e. a Python
function. "def" is a Python keyword and triggers (mostly) Python syntax.
"cdef" requests Cython's extended (C-ish) syntax. All three extensions in
your example ("inline", the return type, and "nogil") are disallowed for
"def" functions, and that will not change. For convenience, argument typing
is allowed, however.

> Same thing if `inline` and/or `bint` are moved into decorators. AFAICT
> @cython.wraparound and @cython.boundscheck work OK.

Interestingly, "nogil" is only implemented as a context manager in current
pure Python mode and not as a decorator. Not sure why, or if this was
intentional. It should probably just be allowed.

Stefan

[Brock Mendel]

> That's because you are defining a "def" function here

I as under the impression that

@cython.cfunc

def [...]

is supposed to be equivalent to

cdef [...]

Is that incorrect?

> Interestingly, "nogil" is only implemented as a context manager in current 
> pure Python mode and not as a decorator. Not sure why, or if this was 
> intentional. It should probably just be allowed. 

I'll be happy to make a PR for this as it is a feature that would make my life better.  Can you point me towards the appropriate spot in the code to put it?

[Stefan Behnel]

Hi,

sorry, looks like I had lost track of your mail.

Brock Mendel schrieb am 22.09.2017 um 19:57:
> On Thursday, September 21, 2017 at 11:42:41 PM UTC-7, Stefan Behnel wrote:
>> Brock Mendel schrieb am 22.09.2017 um 03:49:
>>> It looks like `nogil` does not play nicely with @cython.cfunc and
>> related
>>> decorators. Is this intentional? Example:
>>>
>>> This works:
>>>
>>> cdef inline bint is_string_object(object obj) nogil:
>>> return 0
>>>
>>> This raises Cython.Compiler.Errors.CompileError: Expected '(', found
>> 'bint'
>>>
>>> @cython.cfunc
>>> def inline bint is_string_object(object obj) nogil:
>>> return 0
>>
>> That's because you are defining a "def" function here, i.e. a Python
>> function. "def" is a Python keyword and triggers (mostly) Python syntax.
>

> I as under the impression that
>
> @cython.cfunc
> def [...]
>
> is supposed to be equivalent to
>
> cdef [...]
>
> Is that incorrect?

Equivalent with respect to semantics, not regarding syntax.

>> Interestingly, "nogil" is only implemented as a context manager in current
>> pure Python mode and not as a decorator. Not sure why, or if this was
>> intentional. It should probably just be allowed.
>
> I'll be happy to make a PR for this as it is a feature that would make my
> life better. Can you point me towards the appropriate spot in the code to
> put it?

It should probably go into the InterpretCompilerDirectives class (uses a
visitor pattern, look for "decorators") in ParseTreeTransforms.py. Also, in
Shadow.py (used for uncompiled code), it needs to behave like the other
fake decorators, e.g. "wraparound".

Stefan