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

[Tim Peters]

[Tim]
> 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.

[Peter Funk]
> Obviously you assume, that software written in Python will be bundled
> only with one certain version of the Python interpreter.

Not really.  I think it's more the case that you're viewing this gimmick
through the eyes of your particular problems, and criticizing because it
don't solve them.  However, it wasn't intended to solve them.

> This might be rue 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.

It's not true that Windows is devoid of compatibility problems.  But Windows
Python takes a different approach:  we even rename the Windows Python DLLs
with each release.  That way any number of incompatible Pythons can coexist
peacefully (this isn't trivial under Windows, because we have to install the
core DLL in a specific magic directory).  A serious Python app developed for
Windows generally ships with the specific Python it wants, too (not unique
to Python, of course, serious apps of all kinds ship with the support
softare they need on Windows, up to and sometimes even including the basic
MS C runtime libs).

How people on other OSes choose to deal with this is up to them.  If you
find the Linux approach lacking, I believe you, but the "magical import"
mechanism is too feeble a base on which to pin your hopes.  Get serious
about this!  Write a PEP that will truly address your problems.  This one
does not; I don't even see that it's *related* to your problems.

> ...
> 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.

Yet another reason to prefer Windows <wink>.

> ...
> 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.

The only way to write a piece of code that runs under all of 2.1 thru 2.6 is
to avoid any behavior whatsoever that's specific to some proper subset of
those versions.  That's hard, and I don't think "from __future__" even
*helps* with that.  But it wasn't meant to.  It was meant to make life
easier for people who *do* upgrade in a timely fashion, in accord with at
least the spirit of the existing PEPs on the topic.

> At this time __future__ will contain features, that are 2.5 years
> old.

And ...?  That is, what of it?  In 1000 years, it will contain features that
are 1000 years old.  So?  Else code written now and never purged of obsolete
__future__s would break 1000 years from now.  You can fault the scheme on
many bases, but not on the basis that it creates new incompatibility
problems.  Leaving the old __future__s in will help a little in the other
direction:  code that announces it relies on a __future__ F will reliably
fail at compile-time if run under a release less than F's OptionalRelease
value.

> BTW: We will abstain from using string methods, augmented assignments
> and list compr. for at least the next two years out of similar reasons.

If that's the best you think can you do, so it goes.  It would be nice to
think of a better way.  But this isn't the right gimmick, and that it
doesn't solve your problems doesn't mean it fails to solve anyone's
problems.

> 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... ;-)

That's compatibility:  it worked before under NT and 2000, but not under
Win9X, and it has high newbie appeal (I dove it into after making excuses
about Win9X Beep() for the umpteenth time on the Tutor list).  If you want
to make Linux attractive to newbies, implementing Beep() for it too would be
an excellent step.  If you like, I'll reserve

    from __future__ import MakeLinuxBearableForNewbies

right now <wink>.