Changing the Division Operator -- PEP 238, rev 1.12

[Aahz Maruch]

[posted to c.l.py, with cc to Guido because of the delay]

[I've been busy for a few days, plus I needed some time to let my
thoughts (and the discussion) settle a bit.  I've double-checked against
a skim of revision 1.14, and I don't see a clear statement about this
issue, nor any mention of my suggested solution.]

In article <mailman.996263475.24304.python-list at python.org>,
Guido van Rossum  <guido at zope.com> wrote:
>
>Alternatives
>
>    In order to reduce the amount of old code that needs to be
>    converted, several alternative proposals have been put forth.
>    Here is a brief discussion of each proposal (or category of
>    proposals).  If you know of an alternative that was discussed on
>    c.l.py that isn't mentioned here, please mail the second author.
>
>    - Use a directive (or some other way) to specify the Python
>      version for which a specific piece of code was developed.  This
>      requires future Python interpreters to be able to emulate
>      *exactly* several previous versions of Python, and moreover to
>      do so for multiple versions within the same interpreter.  This
>      is way too much work.  A much simpler solution is to keep
>      multiple interpreters installed.

Actually, I don't necessarily agree with the conclusion of this
alternative.  It occurs to me that we could make good use of a directive
even without bringing forward old behavior.  As I see it, the major
criticism of this proposal is the potential for silent breakage of old
code, with a secondary concern about the ability to maintain code across
multiple Python releases.

If we make a directive a requirement of the Python language starting in
version X.Y (let's assume Python 3.0, but it might be earlier), all old
scripts will fail loudly.  This is a Good Thing.

People will still want to try running their old scripts, so we'll permit
the directive to refer to older versions of Python.  *All* that the
directive will do is spit out warnings and errors during the compile
phase (e.g. if it sees a division operator).  Because this is a hook
that doesn't affect the rest of the interpreter, maintaining it should
be simpler, and there isn't anywhere near the baggage effect.

Given all the other discussion that's gone on, I shan't whine if my
proposal doesn't get accepted, but I think the PEP still needs a clear
statement about the silent breakage that's possible under the current
plan.
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Hugs and backrubs -- I break Rule 6                 http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het Pythonista   

"activist for accuracy"  --SJM