On Mar 11, 2009, at 5:14 PM, Carl Witty wrote:
> On Wed, Mar 11, 2009 at 4:38 PM, Robert Bradshaw
> <[email protected]> wrote:
>> I think this is neither the first nor last issue that will come up
>> like this. What I think we should do is have a "-pedantic" flag which
>> obeys Python semantics exactly, at the expense of speed. This applies
>> to %, //, **, etc. (Overflowing is a separate issue, and I think
>> there should be a flag for that too.) Compilation of .py files would
>> be, by default, with -pedantic enabled, and compilation of .pyx files
>> with it disabled.
>>
>> If one suspects that something subtle like this is changing your
>> algorithm, you can compile with -pedantic and confirm (or deny) your
>> suspicions. Also, everything that differs will query this flag in the
>> code, making it easy to find and *document* the discrepancies. In
>> fact, the annotate feature could even make note of such places.
>>
>> Thoughts?
>
> This doesn't feel like quite the right plan... Consider a file which
> is edited by both an expert (defined as "somebody who happens to
> remember that C and Python have different semantics for signed
> division") and a novice (defined as "somebody who doesn't remember
> about any signed division issues"; note that the same person can be an
> expert one day and a novice the next). If the novice is going to be
> switching -pedantic on and off, doesn't that mean that the expert had
> better write code that works either way? That seems worse than being
> able to depend on one behavior or the other.
I wasn't imagining something people would be switch on and off... it
would be more of a useful tool for when people are converting Python
code to Cython code. We could make this a pragma too.
> Maybe this would be OK combined with builtins ("floordiv"/"floormod"
> and "truncdiv"/"truncmod", perhaps) that were guaranteed not to change
> with -pedantic.
Yes, I think we could provide such functions as well, though it may
be cumbersome to use them. Surrounding functions/blocks by pragmas
would do the trick as well, in case one needed to depend on a certain
behavior. Most of this stuff is corner cases that are just slower to
test/special case for, and people wouldn't be using Cython if they
didn't care about speed.
One of the primary advantages of this approach is that it would
facilitate very good documentation about exactly what (and why) there
are any discrepancies between pure Python and Cython code--and yes
I'm making the assumption that sometimes it's worth doing some things
differently with C types for efficiency reasons.
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
