On Apr 12, 2010, at 6:35 AM, Lisandro Dalcin wrote: > On 12 April 2010 04:10, Stefan Behnel <[email protected]> wrote: >> >> > * 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...
I think a class decorator would be even more natural 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) ?? I like this idea. >> >> > * 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 . Yep, we changed to unsigned + signed = unsigned unless one is wider a long time ago. >> > * 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 ;-) I have no idea what these even mean, so I'll defer to you with a bias towards backwards compatibility. >> > * 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 Lets defer this change until I can make sure the Sage codebase is clean. We should make it a visible warning at least first. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
