Skip to content
jdemeyer edited this page Apr 3, 2017 · 5 revisions

See also the relevant section of enhancements.

Unsupported Python Features

One of our goals is to make Cython as compatible as possible with standard Python. This page lists the things that work in Python but not in Cython.

See also the relevant tickets in the bug tracker:

Cython 1.0 tickets

Issues with Python semantics

Issues with Python 3 semantics

Nested tuple argument unpacking.

def f((a,b), c):
    pass

This was removed in Python 3.

Injecting symbols via globals() ^^^^^^^^^^^^^^^^^^^

By default, Cython throws a compiler error if you use an undefined symbol, e.g.:

print variable_not_defined_anywhere

This is because the vast majority of the time it indicates an actual error. If you need this behavior (e.g. to get the following to work):

globals()['variable_not_defined_anywhere'] = 100
print variable_not_defined_anywhere

set the compiler option Cython.Compiler.Options.error_on_unknown_names to False when compiling your .pyx file.

Function attributes

Though it's generally transparent to a Python user, Python has several different kinds of function objects; in particular one for C-defined functions (a.k.a. function pointer wrappers) and one for Python-defined functions (a.k.a. bundles of bytecodes):

>>> type(lambda: None)
<type 'function'>
>>> type(len)
<type 'builtin_function_or_method'>
>>> type(list.append)
<type 'method_descriptor'>
>>> type([].append)
<type 'builtin_function_or_method'>

Historically, Cython's functions have been of the former type, which unfortunately are missing some attributes:

>>> sorted(set(dir(lambda: None)) - set(dir(len)))
['__closure__', '__code__', '__defaults__', '__dict__', '__get__', '__globals__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name']

We now create our own new type, and plan to make this as similar to "normal" Python functions as possible (clearly func_code.co_code won't contain bytecodes, but most can be emulated pretty well).

>>> type(inline("return lambda: None"))
<type 'cython_function_or_method'>
>>> sorted(set(dir(lambda: None)) - set(dir(inline("return lambda: None"))))
['__closure__', '__code__', '__defaults__', '__globals__', 'func_closure', 'func_code', 'func_defaults', 'func_globals']

inspect support

While it is quite possible to emulate the interface of functions in Cython's own function type, and recent Cython releases have seen several improvements here, the "inspect" module does not consider a Cython implemented function a "function", because it tests the object type explicitly instead of comparing an abstract interface or an abstract base class. This has a negative impact on code that uses inspect to inspect function objects.


Accessing the __doc__ attribute in a class does not work. For example, in plain Python, the following would set C.d to the string docstring. Cython on the other hand does not recognize __doc__ as being special:

class C(object):
    """docstring"""
    d = __doc__

Probably won't fix

This is a list of things that fall more into the implementation details rather than semantics, and we may decide not to fix (or require a --pedantic flag to get).

  • Stack frames: Currently we generate fake tracebacks as part of exception propagation, but don't fill in locals and can't fill in co_code. To be fully compatible, we would have to generate these stack frame objects at function call time (with a potential performance penalty).
  • Identity vs. equality for inferred literals.
a = 1.0        # a inferred to be double
b = c = None   # b and c inferred to be type object
if some_runtime_expression:
    b = a
    c = a
print b is c   # C double -> py float happened twice
Clone this wiki locally