[Python-Dev] RE: Please use __progress__ instead of __future__ (was Other situations like this)

[Peter Funk]

Hi,

Tim Peters:
[...]
> Any statement of the form
> 
>     from __future__ import shiny
> 
> becomes unnecessary as soon as shiny's future arrives, at which point the
> statement can be removed.  The statement is necessary only so long as shiny
> *is* in the future.  So the name is thoroughly appropriate.
[...]

Obviously you assume, that software written in Python will be bundled only
with one certain version of the Python interpreter.  This might be true
for Windows, where Python is no integral part of base operating system.
Not so for Linux:  There application developers have to support a range
of versions covering at least 3 years, if they don't want to start 
fighting against the preinstalled Python.

A while ago I decided to drop the support for Python 1.5.1 and
earlier in our software.  This has bitten me bad:  Upgrading the
Python 1.5.1 installation to 1.5.2 on SuSE Linux 6.0 machine at a
customer site resulted in a nightmare.  Obviously I would have saved
half of the night, if I had decided to install a development system
(GCC, libs ...) there and would have Python recompiled from source
instead of trying to incrementally upgrade parts of the system
using the precompiled binary RPMs delivered by SuSE).  Now I have
learned my lessons and I will not drop support for 1.5.2 until 2003.
BTW: SuSE will start to ship SuSE Linux 7.1 just now in the US (it
is available here since Feb 10th).  AFAIK this is the first Linux
distribution coming with Python 2.0 as the default Python.  Every other
commercially used Linux system out there probably has Python 1.5.2 
or older.

> Given the rules I already posted, it will be very easy to write a Python
> tool to identify obsolete __future__ imports and remove them (if you want).
[...]

Hmmm... If my Python apps have to support for example Python from
version 2.1 up to 2.5 or 2.6 in 2003, I certainly have to leave the
'from __future__ import ...'-statements alone and can't remove them
without sacrifying backward compatibility to the Python interpreter
which made this feature available for the first time.  At this time
__future__ will contain features, that are 2.5 years old.

BTW: We will abstain from using string methods, augmented assignments
and list compr. for at least the next two years out of similar reasons.
On the other hand I would never bother with IO-Port hacking to get a
200Hz and 1.5 second long "beep" out of the PC builtin speaker... ;-)

Have a nice weekend and good night, Peter