PEP 236: Back to the __future__

[D-Man]

On Tue, Feb 27, 2001 at 12:11:22PM +0100, Konrad Hinsen wrote:
| 
| But then there's all the code from others that might also break, and
| that I don't want to fix at all. And since some of my code will depend
| on code from others, I won't fix my own code either and stick to
| Python 1.5 instead. Which in turn forces others who depend on my code
| to do the same. Sure, sooner or later everybody will want to use the
| new features of Python 2.1. But by then Python 2.1 will have been
| replaced by 2.2, with its own set of incompatible changes.

This scenario reminds me of Java.  I am working at a place that is
using jdk1.1.8 for a rather new product (started ~2 years ago).  We've
even found a few bugs in that version of javac that won't compile some
of our code.  So why are we using 1.1.8?  We use a 3rd party library
whose vendor only supports 1.1.8, because they intend it to be used in
applets and many browsers don't have a newer vm.  (Using a different
compiler, but outputing backwards compatible bytecodes allows us to
work around the compiler bugs)

(for those who don't know, jdk1.3.0 has been available for quite a
while now)

| 
| If, on the other hand, incompatible changes occur only every five
| years or so, then people will be inclined to install two Python
| distributions in parallel and update their code over a period of a few
| months.
| 
| Moral: incompatible changes should happen on a time scale compatible
| with uncoordinated collective code development, which is years, not
| months.

I guess the key is how incompatible are the changes?  If it is like
Java, where the event model, GUI toolkit, and standard library had
major incompatibilities, it is bad.  If it is like Tim describes
Python's past then it shouldn't be so painful.  (I don't know from
experience since I first learned of Python at version 1.5.2)


However, I would like to see the use of particular future_statements
deprecated or even disallowed after the feature becomes mandatory.
Once the code has been changed to use the new feature, and the
interpreter mandating that feature is commonly in use, the
future_statement simply clutters the code with extra unnecessary
baggage.  Next thing we know, curly braces will be optional <wink>.
As for the future statement being easy to find :
    grep -r "__future__" my_source_tree/*
will do the job ;-).


-D