On 12 April 2010 04:10, Stefan Behnel <[email protected]> wrote: > Gregory Ewing, 12.04.2010 02:31: > >> * 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. >
Big +1 from my side. About code breakages: Cython could use a compiler directive for this in order to get the old behavior. > > > * 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 > I agree with Stefan here... Moreover, Cython currently uses bracket for the 'type' and 'object' specifiers of extension types, but perhaps it should use Foo(type=FooType, object=FooObject) ?? > > > * 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? > I'm working right now on this to try to backport the change in order to simplify the code in PyrexTypes.py IIUC, the Cython and Pyrex behave the same, though Pyrex's code is simpler, so worth to backport . > > > * 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. > I've addedd __fastcall support long ago. About the other change, I think that not assuming __cdecl as the default is the right thing to do, so we should check for this in Cython. I could try to review this, unless a interested Windows user/contributor beats me ;-) > > > * 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 > +1 -- Lisandro Dalcin --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
