Changes in Pyrex 0.9.6
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:
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__.
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.
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
- In some later version, a __new__ method will be re-introduced with different semantics.
Re-raising exceptionsA 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,
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 wordsTo support some of the new features described below, the following identifiers are now reserved words:
with DEF IF ELIF ELSE
Char arguments to Python functionsPreviously, 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 generationPyrex 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
C function cimporting and API generationTop-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 facilitiesThe 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 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 builtinsCalls 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 extensionA 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 assertionsIf
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.)
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 conventionsThe 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 relaxedAn 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,