Ryan Hinton wrote: > One more quick thought. The first sentence of the Cython tutorial > (chapter two of the manual): > > The fundamental nature of Cython can be summed up as follows: Cython is > Python with C data types. > > I understand there are thorny corner-cases and even common cases where > it's best to break with Python semantics. This may be one of them. But > I remembered this sentence in the shower this morning as I was trying to > figure out why I so strongly expected Python semantics on operators. I > suppose this is more personal reflection, though, since I'm fine if it > remains C semantics -- as long as it is clearly documented. Perhaps a > Wiki page, FAQ entry, and/or manual entry of differences between Cython > and Python. >
+1 on Python semantics for the above reasons. I'm a more casual Cython user. At one point, I thought someone (Robert B?) said that python code should run unmodified as Cython code, and if it didn't, that was a bug (or at least, wasn't implemented yet). That shaped my opinion that Cython was more Pythonic than C *plants tongue in cheek* Besides, Cython has *five* letters in common with Python, and only *one* letter in common with C. Clearly, that helps us see where the priorities should be :). That said, I'm sure I'll adjust to whatever is decided. I can see remembering to change things to C semantics being frustrating, though. Thanks, Jason > Thanks! > > - Ryan > > Ryan Hinton wrote: >> Robert, >> >> Since I hit the problem I'm motivated to chime in. I also followed the >> email trail on the cython list. >> >> Quick summary: >> >> [X] Let the programmer decide, with >> [X'] Get 4 as the default >> >> There are obviously some cases where speed is paramount and others where >> Python compatibility is paramount, so it would be nice to choose. >> Echoing the cython list, I also prefer in-code directives over compiler >> options (though the two need not be mutually exclusive -- just a matter >> of development time). >> >> But given the ability to choose, you still need a "default": which >> semantics are operative without any compiler options or pragmas. Even >> though I "grew up" writing C, I came to Cython gradually from Python >> code, making small changes to see what speed-ups I could get. So I >> assumed Python semantics were operative. Besides my use case and >> personal preference, I think it's more pleasant to add a pragma from a >> wiki page of optimizations than to get really frustrated debugging >> because you made one little change and now your code segfaults (my >> experience). >> >> Thanks for working on this! >> >> - Ryan >> >> Robert Bradshaw wrote: >>> Here's a quick poll. >>> >>> In Python, if I write "-1 % 5", I get 4. This is how we do it in Sage >>> as well (and I think it's the right way--that's not what I'm trying >>> to ask). However, in C if I write "-1 % 5" I get -1. The question is, >>> what should I get in Cython if I write (a % b) where a and b are cdef >>> ints? Should I >>> >>> [ ] Get 4, because it should behave just like in Python, even though >>> it will require extra logic and be a bit slower >>> >>> [ ] Get -1, because they're C ints, and besides we wouldn't be using >>> Cython if we didn't care about performance >>> >>> [ ] Let the programmer decide (e.g. using http://wiki.cython.org/ >>> enhancements/compilerdirectives ) recognizing that % will mean >>> different things in different contexts. >>> >>> - Robert >>> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to sage-devel-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
