Booleans, integer division, backwards compatibility; where is Python going?

[Tim Churches]

Paul Rubin wrote:
> 
> Peter Hansen <peter at engcorp.com> writes:
> > No, that's "stagnant"...
> >
> > Stable is also a good adjective for it, since most of the older
> > code still runs unchanged, and Python from ten years ago is
> > still very recognizable to new coders today.
> 
> Stable doesn't just mean old scripts run without change in new
> interpreters.  It also means new scripts usually run without change in
> old interpreters.  That's what keeps breaking in Python.

I sometimes use a statistics package called Stata. It has been around
for 
well over a decade, with major upgrades to the core language released
about every two years or so - hence there are three or four versions in
common
use. In order to allow users who are still running Stata V4
to write routines which will behave correctly in Stata V7 (and vice
versa),
Stata has a "version" statement. If I am running Version 7, I can put
something like
"USE VERSION 4" (I don't recall the exact syntax) at the top of my
programs 
and the program will be executed as if it were running in Stata V4.
Hence, a user 
who still runs Stata V4 can put "USE VERSION 4" in every program and be
sure these 
will work correctly when run in all subsequent versions of Stata. 

This is the equivalent, I think, of having a "from __past__ import *"
statement 
in Python, or more precisely, a "from __v1.5.2__ import *" statement. 

Obviously it is impossible to retrospectively provide support for such a
statement,
but if there were a "from __v2.2.2__ import *" statement, one could put
that at the 
beginning of every Python module one writes and be certain that the Bool
type or any other
newfangled feature would not trip up one's code at any time in the
future, no matter how
recent the version of Python used to execute it. Similarly a user of a
recent version could 
verify that their code runs OK with older versions by using such a
statement, which would
of course disable all new language features and library modules, as well
as making any new 
language behaviour revert to the old.

However, it may not be possible to avoid bloat because successive
versions of Python would need
to support more and more old behaviour, but if this backwards support
could be relegated to
the libraries, it shouldn't be too bad. Bloat in the Python core in
order to support
historical behaviour would be a lot less desirable, though.  

And of course, such support for historical features and behaviour may
result in ever 
increasing intervals between releases of new versions of Python, as the
developers 
struggle to accomodate ever more historical baggage.

Hence I don't think that any of the above is a good idea.

Tim C