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.
Stefan
PS: Dag, I read your comment on "(2147483647 + 2147483647)" wrapping
around in current Cython. I never thought about that, simply since I never
ran into it. However, when I write
py_large_val = 2147483647 + 2147483647
it must never wrap around as it clearly requests Python semantics, and
when I write
cdef uint64 c_large_val = 2147483647 + 2147483647
it must not wrap around either. I'm fine with a wrap-around in
cdef int c_large_val = 2147483647 + 2147483647
though, because that's what the user a) requested or at least b) must be
aware of when explicitly assigning types. So that's clearly different from
a discussion on operator semantics.
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
