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.
Maybe this would be OK combined with builtins ("floordiv"/"floormod"
and "truncdiv"/"truncmod", perhaps) that were guaranteed not to change
with -pedantic.
Carl
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
