Future division patch available (PEP 238)
chrishbarker at home.net
Tue Jul 24 23:37:12 CEST 2001
Guido van Rossum wrote:
> I think it will be inevitable for many Pythons to come to provide a
> way to turn off the new division rules. I am currently working on a
> command line option for this.
That may be true, but I think it is unfortunate. Having command line
options means that we allow different dialects of the language that are
indistinguishable by just looking at the code.
Python is an evolving language. I, for one, am very happy about that (I
was ecstatic about the addition of rich comparisons, among other
things). It does mean that code written with 2.1 in mind will not run on
1.5.2, but that's not too bad. What is bad is that code written for
1.5.2 might not run on a version 2.4 interpreter. A lot of folks have
made it very clear that that could cause a LOT of problems. I agree, and
I think we really can evolve the language without causing that kind of
Some folks have suggested a "from __past__" type construct, or a "from
numeric import new_division". Neither of these is a good approach. the
from __past__ requires old code to be changed (even if just a little),
and the from numeric... means that there will be a number of different
dialects of the language. At least you can tell form the source which
dialect you are using, but i f you are writing code, and using other
code, you could get pretty confused.
It seems to me that Python's evolution is a one way street: for the most
part features are added, and occasionally (rarely, I hope) a backwards
incompatibility is introduced. Since it is a one way street, I think it
is reasonable for new code not to run on old interpreters, we've
accepted that already. What to do about old code running on new
As of Python 2.2 (or 2.3, whatever, as long as it is as soon as any
backward incompatibility is introduced) require something at the top of
every source file: a line like:
This is now an indicator of what version of Python the code runs under.
If that line is not there, it is assumed that it is for a version less
that 2.3: In that case, the interpreter has a backward compatibility
mode, and runs that code in that mode. This could probably be a change
at the compiling level, and the resultant byte code could be compatible.
The nice thing about this approach is that it:
A) will not break old code. Ever. At all.
B) It sets up a system for other changes that might be backward
incompatible as well. Let them be few and far between!
C) it restricts the different dialects to being only version changes,
and only a one way street. I think this is a good thing: I don't want
Python coders in the future to be able to use a version that has, for
the old division, but case insensitive
the new division but case sensitive,
old division, case sensitive, but with all the other new features of
If you allow people to choose, through command line options, or some
version of import, each of these features separately, you will have a
Guido, (and everyone else) I'd love to hear your take on this proposal,
I'm sure it's full of holes, but I don't what they are. I started a
thread about it, and have gotten responses, but no one has actually
commented on the proposal itself.
See the thread: "A way to accommodate laguage changes" I went into a
little more detail there. I also misspelled language!
ChrisHBarker at home.net --- --- ---
http://members.home.net/barkerlohmann ---@@ -----@@ -----@@
------@@@ ------@@@ ------@@@
Oil Spill Modeling ------ @ ------ @ ------ @
Water Resources Engineering ------- --------- --------
Coastal and Fluvial Hydrodynamics --------------------------------------
More information about the Python-list