Cython in pure mode generates bogus interaction with Python when using PEP484/526 syntax instead of decorators

[sturlamolden]

If I annotate a function using PEP484/526 syntax

import cython

@cython.cfunc
def fib(n : cython.int) -> cython.int:
    if (n<=1):
        return n
    return fib(n-1) + fib(n-2)

cython -c tells me the last line interacts with Python, basically checking PyErr_Occurred().

Whereas if I use decorators, there are no such checks, and Cython generates the same C code as it would with Pyrex syntax:

import cython

@cython.cfunc
@cython.locals(n=cython.int)
@cython.returns(cython.int)
def _fib(n):
    if (n<=1):
        return n
    return _fib(n-1) + _fib(n-2)

The return line using PEP484/526 syntax looks like this

+08:     return _fib(n-1) + _fib(n-2)
  __pyx_t_2 = __pyx_f_46_cython_magic_dd8e3b97486038017346fa36994a0695__fib((__pyx_v_n - 1)); if (unlikely(__pyx_t_2 == ((int)-1) && PyErr_Occurred())) __PYX_ERR(0, 8, __pyx_L1_error)
  __pyx_t_3 = __pyx_f_46_cython_magic_dd8e3b97486038017346fa36994a0695__fib((__pyx_v_n - 2)); if (unlikely(__pyx_t_3 == ((int)-1) && PyErr_Occurred())) __PYX_ERR(0, 8, __pyx_L1_error)
  __pyx_r = (__pyx_t_2 + __pyx_t_3);
  goto __pyx_L0;

whereas with decorators it looks like this

+11:     return _fib(n-1) + _fib(n-2)
  __pyx_r = (__pyx_f_46_cython_magic_6c3a15eed3bce3137103a8464b16a811__fib((__pyx_v_n - 1)) + __pyx_f_46_cython_magic_6c3a15eed3bce3137103a8464b16a811__fib((__pyx_v_n - 2)));
  goto __pyx_L0;

[scoder]

Hmm, I thought that this was documented, but at least I can't find it right now.

This is intentional. When you use Python type annotations, it would be weird if you lost Python exception propagation semantics along the way, just by compiling the code. So the default behaviour is "except? -1" here for C integer types.

cython/Cython/Compiler/Nodes.py

Lines 701 to 710 in 25d042d

	if self.exception_value is None and self.exception_check and self.exception_check != '+':
	# Use an explicit exception return value to speed up exception checks.
	# Even if it is not declared, we can use the default exception value of the return type,
	# unless the function is some kind of external function that we do not control.
	if return_type.exception_value is not None and (visibility != 'extern' and not in_pxd):
	# Extension types are more difficult because the signature must match the base type signature.
	if not env.is_c_class_scope:
	from .ExprNodes import ConstNode
	self.exception_value = ConstNode(
	self.pos, value=return_type.exception_value, type=return_type)

Arguably, this would also be a better default for the decorator case. Probably worth discussing if Cython 3.0 is a good time to change it there as well.

[scoder]

See a3ffd72, looks like this has been around since 0.27.

[h-vetinari]

This is intentional. When you use Python type annotations, it would be weird if you lost Python exception propagation semantics along the way, just by compiling the code.

Even if those type annotations use cython types (as in the OP)? Could those annotated types not be inspected whether they actually need python?

[scoder]

Could those annotated types not be inspected whether they actually need python?

I read your question as "could those annotated functions not be analysed to see if they actually raise exceptions", is that what you meant? Then the answer is: yes, not entirely easily, but they could. We currently only let that analysis fall out for free at code generation time, but do not have it available when we determine the function type. It would be an improvement in this case. But lacking that earlier analysis, I think safe exception raising is better than silently ignoring them.

[scoder]

Also note that the exception check is really cheap here, especially since -1 is not even a normal return value in the example at hand. I'd be surprised if it cost more than one CPU cycle on average.

[sturlamolden]

It it were documented, I would not had spent time convincing myself that is was a bug :)

In my timings for the Fibonacci toy function the exception check accounts for 10% of the run-time. I guess that is quite unsignificant as the function does not do much but recurse, add, and error check.

Anyhow, with some experimentation I found that this combination is what is needed to make an annotated function behave like a "real" C function:

@cython.exceptval(check=False)
@cython.cfunc
@cython.nogil
def fib(n : cython.int) -> cython.int:
    if (n<=1):
        return n
    return fib(n-1) + fib(n-2)

Maybe it should be documented to avoid any surprises.

[scoder]

PR welcome, as always :)

[h-vetinari]

@scoder: This is intentional. When you use Python type annotations, it would be weird if you lost Python exception propagation semantics along the way, just by compiling the code.

@h-vetinari: Even if those type annotations use cython types (as in the OP)? Could those annotated types not be inspected whether they actually need python?

@scoder: I read your question as "could those annotated functions not be analysed to see if they actually raise exceptions", is that what you meant?

I was responding mainly to "python type annotations" (my bold), and how the OP used type annotations, but not python ones. But IIUC, you're saying that the (python) types are much less relevant here than the (python) exception behaviour.

I don't think analysing functions for whether they raise or not is reasonable. But maybe having a way (another decorator?) to indicate that the function will not raise (or shouldn't be checked for exceptions) would provide what's desired here?

[sturlamolden]

@h-vetinari After experimenting with the output from cython -a, I found that this is what @cython.exceptval(check=False) does. It turns the exception checking off. The documentation did not indicate this behavior though.

[scoder]

The documentation did not indicate this behavior though.

PR welcome.