Stefan Behnel wrote: > Dag Sverre Seljebotn wrote: > >> Both communities seems to mirror the discussion we've already had here >> very closely. There's one group who sees Cython as "fast Python" who >> want Python semantics and another who sees it as "mixed Python and C" >> who want the C semantics. >> > > I was also rather unsure at the beginning, but when I think of the > consequences for totally Python-looking Cython source code like > > [ y % 5 for y in some_iterable ] > > where you have to a) look up the type of "y" *and* b) know the associated > semantics of the % operator, before you even know what the numeric range > of the result will be - I think that having C semantics here is just too > dangerous to be the default. We should not forget that the syntax we write > in is Python, so it's a sure trap to assign C semantics to obvious looking > things like the above. > > My clear vote is for Python-semantics on "x%y" and for a helper function > "cython.cmod(x,y)" that boils down to a straight and fast C mod operator > without value fixing. > Agreed...but like Robert I'm worried about the usability of requiring to use cython.cmod and cython.cdiv (the latter being kist as important here); especially as one would typically use them in lots of situations (where one is only dividing positive integers anyway) to avoid the speed penalty (the 20% penalty reported by William is a bit much!).
So I'm myself leaning towards new operators (in addition to cython.cmod/cdiv) for the C semantics (e.g. /- and %-, or ^/ and ^%, or similar -- as long as we stay away from /~ etc which is proposed in some PEPs). Yes, this is ugly! -- but I see them as less ugly than the alternatives. It seems that tomorrow I may have a different opinion though, so I may just let the matter rest for some days for what I'm concerned. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
