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:
Nested tuple argument unpacking.
def f((a,b), c): pass
This was removed in Python 3.
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']
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.
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 # a inferred to be type object if some_runtime_expression: b = a c = a print b is c # c double -> py float happened twice