Changing the Division Operator -- PEP 238, rev 1.12

[Guido van Rossum]

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

I'm no longer following the newsgroup.  It's simply not worth it --
I've seen every argument about 10 times now.  There are many others
who will bring new developments to my attention if they deserve it (or
respond if they don't), so there's no need to mail me copies of
posts.  (Nevertheless, I appreciate this one.)

> 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.

I accept that I cannot seem to explain it well enough, but requiring a
version directive on all code strikes me as extreme ugliness.  I guess
the problem I have with it is that it's overspecified.  If I write
code for version X.Y and explicitly state so, it's possible that it
breaks with X.(Y+1) and X.(Y-1) but just as likely that it doesn't.
There just isn't any telling (from the version directive) what
features I'm using that are unique to version X.Y.

> 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.

But in all likelihood, most old scripts will in fact run fine on 3.0,
and won't require any backwards compatibility.  (Python 3.0 is not
Perl 6!)

> 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.

I expect that the noise generated by these warnings would overwhelm
the useful warnings so that most people will turn them off.

I am trusting that people will not switch from Python 2.x to Python
3.x without doing an upgrade check on their Python code.  It should be
easy enough to create a program along the lines of PyChecker that does
a compatibility check.

> 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, would you mind proposing some language?  I seem to have lost my
normal ability to see things from someone else's point of view in this
case.

--Guido van Rossum (home page: http://www.python.org/~guido/)