Lisandro Dalcin wrote: > On Wed, Mar 11, 2009 at 5:34 AM, Dag Sverre Seljebotn > <[email protected]> wrote: > >> Carl Witty wrote: >> >>> I just reported http://trac.cython.org/cython_trac/ticket/229, which >>> points out that division and % on cdef ints have C rather than Python >>> semantics (for instance, (-1 % 16) is -1 in C, and 15 in Python). >>> >>> I'm not sure what the right thing to do here is. Using C semantics >>> gives faster code. Using Python semantics is nicer (whenever I care >>> about the difference, I always want Python semantics) but slower, and >>> would be confusing to somebody who was coming from C. >>> >> I'm +1 on Python semantics. We could make the C version available under >> some obscure name for any case when one really wants the speed, like >> cython.fast_c_mod(-1, 16). >> >> > > I'm no so sure... C is C, Python is Python, and Cython is in the > middle, but a cdef int is IMHO on C side... Are we going to upcast > '1/2' to a float? > I think we should follow Python convention, i.e. "from __future__ import division" means this behaviour, and if the code (in the future) is Python 3-level, then that should be the default (as you say there's always the //). > Still not sure about this... > > Dag, some long time ago, when I asked to suport s"abc" string > literals, you told me that such feature is easily implemented on users > side with a tiny function and doing s("abc") ... Well, you were right, > but I believe so I am, users can always implement c = mod(a,b) to > return what they want ;-) > Sure :-) Syntax is mostly a matter of taste in the end. But the deeper reason behind my arguments is this:
A rather typical usecase of Cython, which I believe we should encourage, is to a) first implement things in Python (or at least in untyped Cython) b) profile (or at least experience that things are too slow) c) find out which functions you bother to type, and incrementally type your program "bottom up". Now, if we suddenly change the meaning of operators depending on whether they operate on Python ints or C ints, it means that an algorithm that worked perfectly in step a) will break in step c). Which just means more hassle, and that step c) become a bigger job than it needs to be. Therefore I believe that the "C" part of Cython should mean "it is easy to call C and work with C types", but that the operator semantics should be as close to Python as possible. (Modulo overflowing, but as I said I hope for a overflowcheck compiler directive as well to help while doing step c), which can then be turned off). Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
