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.

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:

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,