Pyrex

Pyrex is a language designed for creating Python extension modules written in C code.

It's designed to bridge the gap between the nice, high-level, easy-to-use world of Python and the messy, low-level world of C.

For the basic types such as numbers and strings this is not too bad, but anything more elaborate and you're into picking Python objects apart using the Python/C API calls, which requires you to be meticulous about maintaining reference counts, checking for errors at every step and cleaning up properly if anything goes wrong.

What is new in this release:

• Some features for interfacing with C++ code have been introduced in this release.
• Pyrex no longer places caught exceptions into the thread state. This ensures that exceptions and tracebacks do not leak out of the except clause that caught them, unless you do something to explicitly preserve them.
• Currently, an argument to a Python function that is declared as an extension type will, by default, be allowed to receive the value None; to prevent this, you must qualify the argument declaration with 'not None'.
• It is now possible to define and extension type with Python attributes that does not participate in cyclic garbage collection, using a new nogc option.
• size_t is now a built-in type and is the type returned by the sizeof operator. Also, the sizes of size_t and Py_ssize_t are now assumed to be somewhere between long and long long.
• Operations between two int types of the same rank now return an unsigned result if either of the operands is unsigned; if the ranks differ, the result has the same type as the wider-ranked operand. I think this is the best approximation of the ANSI C rules that is possible without knowing the exact sizes of the types.
• PyString_InternFromString is now exposed under the name cintern rather than intern, because it is not a complete replacement for the Python intern function (it can't handle strings containing null bytes).
• The size check that was previously generated when importing an extension type has been disabled for the time being until I can think of something better. It was generating too many false positives, for example from different versions of numpy.
• The __fastcall calling convention option is now supported. Also, Pyrex no longer assumes that __cdecl is the default calling convention. To be considered compatible, two function types must either be declared with the same calling convention, or both must leave it unspecified.
• As I have been threatening for some time, using __new__ as the name of the initialisation method of an extension type has become an error rather than just a warning. In some future release, __new__ will re-emerge with more Python-like semantics.

Limitations:

nothing found