[Pyrex] ANN: Pyrex 0.9.9

[Stefan Behnel]

Gregory Ewing, 12.04.2010 02:31:
> Pyrex 0.9.9 is now available:
>
> http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/

 > A more detailed discussion of these changes can be found
 > in the release notes here:
 >
 > 
http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Release_Notes_0.9.9.html


> * Some facilities for interfacing with C++ code have been
> added.

Looks like Pyrex and Cython are really starting to diverge syntaxwise for 
similar features.

http://www.cosc.canterbury.ac.nz/greg.ewing/python/Pyrex/version/Doc/Manual/using_with_c++.html

http://wiki.cython.org/WrappingCPlusPlus


> * Changes have been made to the semantics of exception
> catching to improve efficiency.

Since this violates Python semantics, I guess this will stay a Pyrex-only 
feature. A similar kind of behaviour could only appear in Cython if the 
except clause could be determined to be free of code that required those 
Python semantics, which I guess is hard enough to prove to make it mostly 
worthless. (Note that the except-pass case is already optimised in Cython.)


> * Preparation is being made for making 'not None' the
> default for extension type parameters to Python functions.

I agree that this has been a source of bugs in the past, so I'm not 
generally opposed to this. I really dislike breaking existing code, but I 
would expect that this is only a minor source of trouble for users. I'm 
+0.3 for such a change in Cython.


 > * Non-GC Extension Types

+1 for the feature, -1 for the syntax. Python 3 has keyword arguments in 
the baseclass tuple, so this would be much better here:

     cdef class Spam(gc=False):
         cdef object sausage


 > * 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.

I'm not sure how Cython handles this - can anyone comment?


 > * 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 way Cython currently handles intern() is that it only works at the 
Python level, requiring byte string input in Py2 and unicode string input 
in Py3. Given this behaviour, I would expect that "cintern" returns the 
native 'str' type for each platform. BTW, note that intern() is no longer a 
builtin in Py3.

In Cython, neither of the two C-API functions that work on char* are 
currently exposed at the language level, so interning from a char* only 
works in Py2 (where it does exactly the same as a call to 
PyString_InternAsString due to the normal string coercion semantics).

It would become a little funny if "intern(char*)" worked in Py3 but 
"intern(bytes)" didn't, so I'm reluctant to enabling support for char* in 
Py3. That would be the only reason to use a new builtin, I guess, so I'm 
+0.5 for supporting it.


 > * 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.

IIRC, Cython has also stepped back from this, but still has some kind of 
check enabled. Don't remember the exact details.


 > * 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.

Can't comment on this, but worth considering for Cython as well, I guess.


 > * 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.

I have wanted __new__ support for quite a while now, so I think this is the 
right thing to do. Cython already has a ticket about __new__, and we 
discussed this feature before I opened it, so no problem here, I guess.

http://trac.cython.org/cython_trac/ticket/238

Stefan