Changes in Pyrex 0.9.6

Language Changes

Renaming new to cinit

In a future version of Pyrex, I would like to make it possible to give an extension type a __new__ method that works more like the standard Python __new__. As a first step towards that, I am renaming Pyrex's current __new__ method to __cinit__. The migration plan is as follows:

In Pyrex 0.9.6, a warning is given whenever you define a __new__ method for an extension type, and it is automatically renamed to __cinit__ for you. This will allow existing Pyrex code towork unchanged for the time being.
In Pyrex 0.9.7, the warning will become an error, and no renaming will be performed. You will have to update your source to use __cinit__ instead of __new__.
In some later version, a __new__ method will be re-introduced with different semantics.

If you still have code around which uses __new__ in the old way by the time step 3 arrives, it will either fail to work or work incorrectly. It is recommended that you begin updating your Pyrex source now to use __cinit__ instead of __new__.

Re-raising exceptions

A raise statement with no arguments (i.e. to re-raise the last exception caught) is now required to be lexically within the except clause which caught the exception,

This change was necessary in order to be able to efficiently preserve the exception in the case where an intervening call raised and caught a different exception. The behaviour of Pyrex is now closer to that of Python when this occurs.

New reserved words

To support some of the new features described below, the following identifiers are now reserved words:

with DEF IF ELIF ELSE

Char arguments to Python functions

Previously, if an argument to a Python function (defined with def) was declared to be of type char, the corresponding Python argument passed was required to be a string. For consistency with the way that automatic conversions are done elsewhere, this has been changed so that it expects a Python integer. To accept a single-character string, you will need to declare the argument as type char * and then extract the first character.

No default .pxi generation

Pyrex no longer automatically generates a .pxi file when you use public declarations in a module. Since the cimport mechanism has taken over most of the use cases for which this was intended, it was felt to be no longer useful. If you really need one, you can get it using a feature of the new distutils extension described below.

New Features

C function cimporting and API generation

Top-level C functions can now be declared in a .pxd file and imported into another Pyrex module using cimport, without the need for any C-level linking between the modules. Also, a new api keyword permits a C API to be generated, allowing these functions to be used from C code in another module, also without any linking. For more information, see Sharing Declarations Between Pyrex Modules and Interfacing with External C Code in the Language Overview.

GIL facilities

The GIL can be acquired on entry to a function by adding a with gil clause to the function's header. Also, a block of code can be executed with the GIL released using a new with nogil statement. For more information, see Acquiring and Releasing the GIL under Interfacing with External C Code in the Language Overview.

Conditional compilation

Some conditional compilation facilities have been added. A DEF statement allows compile-time names to be defined. and an IF/ELIF/ELSE statement allows sections of code to be conditionally included based on compile-time expressions. For more information, see Conditional Compilation under Language Basics in the Language Overview.

Fast calls to builtins

Calls to the following Python builtin functions are now compiled as direct calls to the corresponding C API routines:

abs delattr dir divmod getattr hasattr hash intern
isinstance issubclass iter len pow reload repr setattr

New distutils extension

A new version of the distutils extension is included, with an Extension type that supports the following extra options.

pyrex_include_dirs	list of strings	list of dirs to search for Pyrex header files
pyrex_create_listing_file	boolean	write errs to listing file
pyrex_cplus	boolean	generate C++ code
pyrex_c_in_temp	boolean	put generated C files in temp dir
pyrex_gen_pxi	boolean	generate .pxi file for public declarations

Compiling without assertions

If PYREX_WITHOUT_ASSERTIONS is #defined at C compilation time, assert statements are compiled out. (You will need to include a C header file or use a C compiler command line option to achieve this.)

Py_ssize_t support

Py_ssize_t is now a predefined type known to Pyrex. To make your modules compatible with 64-bit systems, you should use it wherever indicated in the Python/C API documentation.

Windows calling conventions

The Windows __stdcall and __cdecl calling convention specifiers are supported, with the same syntax as used by Windows C compilers. They have no effect when the generated C code is compiled on non-Window systems.

Include statement restrictions relaxed

An include statement can now appear anywhere that an ordinary statement or declaration can appear. The included file can contain any complete statements or declarations that would be legal at the place where the include statement appears. The contents of the included file should start at an indentation level of zero,

---