• enhancements

This is a list of some of the stuff that we'd may like to see in Cython, and many make good starting points for Google Summer of Code projects.

CEPs are isolated ideas and concepts. They do not need to be full specifications; once it is believed that a concept is understood in enough detail that it won't be refactored into other pieces it is a good candidate for a CEP. However as CEPs are implemented they should develop towards a higher level of specificity (and eventually serve as documentation of the feature). Collections of more general enhancement ideas, especially if they are not specific enough to determine what "done" means, should usually be linked under Exploring new concepts.

CEP 1xx - User experience

Improvement for specific usecases or libraries. These are bigger end-goals driving the development priorities and depends on other CEPs for the details.

• CEP 101 - Full Python 2.x syntax support (this is a 1.0 goal)

• CEP 102 - Full Python 3000 support

• CEP 103 - Improved C++ support

• CEP 104 - Better NumPy support

• CEP 105 - Syntax highlighting for common editors

• CEP 106 - Package pxds for common libraries with Cython

• CEP 107 - a special compilation mode that adds safety checks at various places

• CEP 108 - better handling of string literals in Python 3 (Done)

CEP 2xx - Frontend

Build system, command-line interface, library interface

• CEP 201 - Distutils Preprocessing

• CEP 202 - Plugin framework

CEP 3xx - Pure Python support

Supporting more features for pure Python code (without Cython syntax extensions)

• CEP 301 - from blah import * (Done)

• CEP 302 - with statements (Done)

• CEP 303 - closures

• CEP 304 - decorators (Done)

• CEP 305 - semantically correct scope

• CEP 306 - better local variable handling

• CEP 307 - native support for generators and PEP 342 coroutines (yield)

CEP 4xx - Support for wrapping existing C/C++/Fortran/... libraries

Improved support for features in C/C++/Fortran code that is wrapped, often through extensions in the Cython declaration language.

• CEP 401 - Fortran support

• CEP 402 - Passing Python buffers to external code

CEP 5xx - Cython language features

Development of Cython as a language that is not covered by the 3xx or 4xx series.

• CEP 501 - Embedding Cython language extensions in valid Python syntax

• CEP 502 - Function overloading

• CEP 503 - Compile-time operator overloading

• CEP 504 - Easier pickling of cdef classes

• CEP 505 - Type inference

• CEP 506 - Parametrized types

• CEP 507 - Typing variables as Python builtin types

• CEP 508 - Compile-time computation/unrolling of functions

• CEP 509 - Method templates

• CEP 510 - Inlineable code in .pxd-files

• CEP 511 - Metaprogramming support

• CEP 512 - C arrays as first class types

• CEP 513 - pxd overlays on Python modules

• CEP 514 - Native buffer interface syntax support (Done)

• CEP 515 - Compiler directives (Done)

• CEP 516 - Division Semantics (Done)

• CEP 517 - Array type (Not voted for yet)

• CEP 518 - SIMD operations on Cython arrays (Not voted for yet)

• CEP 519 - Signal handling

• CEP 520 - None checks for extension type arguments

CEP 6xx - Optimizations

Generating smarter output C code.

• CEP 601 - Generate C switch statements (Done)

• CEP 602 - Optimizing various for..in-constructs

CEP 9xx - Cython internals

Changes in the internal Cython implementation.

• CEP 901 - Separate code tree transforms

• CEP 902 - Build parser from grammar file

• CEP 903 - Abstract syntax treeAST

• CEP 904 - Control flow graph

• CEP 905 - Separate phases

• CEP 906 - Refnanny

Exploring new concepts

• Common tree visitor APIs for different trees

• The uneval psuedo-function (unifying metaprogramming approaches)

• An approach to ctypes/types in numpy

• Assumptions

• Vtab optimizations

• If and how to intregrate stuff from PEX

• - build system

• Parallel execution support

• OpenCL support (since cython compiles into c and OpenCL is a subset of c99)
• Supporting C-level conditional compilation (e.g. emitting #ifdef)
• Bound C methods and functions (e.g. supporting cdef closures). This could be done by via a struct holding "self" and the function pointer. The issues are coercion to/from unbound and raw C methods.