[Idle-dev] Forward progress with full backward compatibility

[Glyph Lefkowitz]

Language pragmas are all fine and good, BUT ...

Here in the Real World(TM) we have to deal with version in compatibilities
out the wazoo.  I am currently writing a java application that has to run
on JDK 1.1, and 1.2, and microsoft's half-way JDK 1.1+1/2 thingy.  Python
comes installed on many major linux distributions, and the installed base
is likely to be even larger than it is now by the time Python 1.6 is ready
for the big time.  I'd like to tell people who still have RedHat 6.2
installed in six months that they can just download a 40k script and not a
5M interpreter source tarball (which will be incompatible with their
previous python installation, which they need for other stuff) when I
deploy an end-user application.  (Sorry, I can't think of another way to
say that, I'm still recovering from java-isms...) :-)

What I'm saying is that it would be great if you could write an app that
would still function with existing versions of the interpreter, but would
be missing certain features that were easier to implement with the new
language symantics or required a new core library feature.  Backward
compatibility is as important to me as forward compatibility, and I'd
prefer not to achieve it by writing exclusively to python 1.5.2 for the
rest of my life.

The way I would like to see this happen is NOT with language pragmas
('global' strikes me as particularly inappropriate, since that already
means something else...) but with file-extensions.  For example, if you
have a python file which uses 1.6 features, I call it 'foo.1_6.py'.  I
also have a version that will work with 1.5, albeit slightly slower/less
featureful: so I call it 'foo.py'.  'import foo' will work correctly.  
Or, if I only have 'foo.1_6.py' it will break, which I gather would be the
desired behavior.

As long as we're talking about versioning issues, could we perhaps
introduce a slightly more robust introspective facility than

	assert(sys.version[:3])=='1.5'

?

And finally, I appreciate that some physics students may find it confusing
that 1/2 yeilds 0 instead of 0.5, but I think it would be easier to just
teach them to do 1./2 rather than changing the symantics of integer
constants completely ... I use python to do a lot of GUI work right now
(and it's BEAUTIFUL for interfacing with Gtk/Tk/Qt, so I'm looking forward
to doing more of it) and when I divide *1* by *2*, that's what I mean.  I
want integers, because I'm talking about pixels.

It would be a real drag to go through all of my code and insert int(1/2)
because there's no way to do integer math in python anymore... (Besides,
what about 100000000000000000000L/200000000000000000000L, which I believe
will shortly be lacking the Ls...?)

Maybe language features that are like this could be handled by a
pseudo-module?  I.E.

	import syntax
	syntax.floating_point_division()

or somesuch ...

I'm not sure how you'd implement this so it would be automatic in certain
contexts (merging it into your 'site' module maybe?  that has obvious
problems though), but considering that such features may be NOT the
behavior desired by everyone, it seems strange to move the language in
that direction unilaterally.

                      ______      __   __  _____  _     _
                     |  ____ |      \_/   |_____] |_____|
                     |_____| |_____  |    |       |     |
                     @ t w i s t e d m a t r i x  . c o m
                     http://www.twistedmatrix.com/~glyph/