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.
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 (Done)
- 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 109 - Runtime invocation similar to weave.inline (Done)
Build system, command-line interface, library interface
- CEP 201 - Distutils Preprocessing
- CEP 202 - Plugin framework
Supporting more features for pure Python code (without Cython syntax extensions)
Generating smarter output C code.
Different backends: C, C++ and others
Changes in the internal Cython implementation.
- Common tree visitor APIs for different trees
- The uneval psuedo-function (unifying metaprogramming approaches)
- An approach to ctypes/types in numpy
- 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.
- Better C++ Exception Support
Last edited by Robert Bradshaw,