On Mar 16, 2009, at 7:54 AM, Dag Sverre Seljebotn wrote: > 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"
After reading all the discussion on all the lists (thanks Dag for asking on NumPy as well), my vote is also for the default semantics for "x%y" to be Python semantics. This is primarily to follow the path of least surprise, especially for Python users that don't really know C just trying to make (existing) Python code faster and/or call C libraries (which I view as our main audience). In particular, I think C semantics would be much more surprising to those expecting Python semantics than Python semantics would be to someone expecting C semantics. I have a hunch that the latter group will be more capable of creating a workaround. >> 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. I'm less sure about how to expose the C operations, but just accepting a 20-30% slowdown is not acceptable. We should provide cython.cmod/cdiv, but I feel strongly we should provide an infix option as well. I'm wary of introducing new operators, but the %-, /-, and //- seems like the best options proposed. It is a bit deceptive though, as we would not force the truncating rounding mode for negative numbers, just pass it on to the C compiler (are there any that don't make this choice?). Another option is to do something very like c(%) or c_op(%), which is currently unused invalid syntax. This is very explicit and could generalized to other situations, but it's not as readable and extending the parser should be done with caution. The option I'm leaning towards (which is probably the most controversial) is having a pragma like "cython.cdivision" that controls what the semantics are. This really isn't any more invasive than the from __future__ import division, and we can do it on a more local scale. One reason I like this option are that usually when one wants to use it in one place, one wants to use it consistently throughout a whole block of code, and introducing a new operator is hard to remember to use everywhere. Also, it makes it easy to convert existing code (e.g. the Sage library) and appease those who really want C semantics. I'm not a fan of introducing a new set of types (cint, cfloat, ...) and I think this will make Cython more confusing, especially as they a priori have no indication they have anything to do with division. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
