Lisandro Dalcin, 12.04.2010 15:35: > On 12 April 2010 04:10, Stefan Behnel 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.
... which would mean that users must still adapt their code. If they do that, I think it's better to fix it while you're at it, rather than going with the quick fix of putting in a directive. So I'm -0 on such a directive, given that we can expect the average user code to contain at least a couple of bugs due to a missing None test. If we emit a warning for a missing "or None", it's easy enough to spot where work needs to be done. >> > * 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) ?? Rather "FooType" as a string and maybe something like "ctypename" instead of just "type", but, yes, I like that. >> > * 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 Thanks! > IIUC, the Cython and Pyrex behave the same, though Pyrex's code is > simpler, so worth to backport . Except that "back"-port isn't quite the right word here. ;) >> > * 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 ;-) Let's not wait for that. ;) Stefan _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
