__past__ (Was: Re: PEP-317)

[Jack Diederich]

On Wed, Jun 11, 2003 at 09:16:33PM +0200, Gerrit Holl wrote:
> Roy Smith wrote:
> > "Donn Cave" <donn at drizzle.com> wrote:
> > > "Never" would be a reasonable schedule, hope that's constructive.
> > > The reasons advanced for breaking currently valid "raise" statements
> > > would be excellent for a newly introduced feature, but those same
> > > excellent sentiments add up to "gratuitous" here.  Break things
> > > only when necessary, not just for the sake of tidiness.
> > 
> > I have to agree with that.  I'm all for making stuff better, but if it 
> > means breaking something that currently works, it's a bad idea.  I'd 
> > much rather live with a few "historical warts" in the language than have 
> > to put up with working code breaking.
> 
> How about a __past__ pseudo-module?
> 
> from __past__ import string_exceptions # for those to lazy to update their code
> from __past__ import access
> from __past__ import implicit_instatiation
> # etc.
> 
> This makes letting something work again a *lot* easier. It is easy
> to automate this if the interpreter it was written for is known.
> Hmm... Python could have a --past commandline argument that tries
> to run code, and when it fails, tries to find out whether it is
> because of backwards incompatibility or not; if it is, it can (at
> the users wish, of course) add these lines to the code. This would
> more or less enforces new users to use new-style code. 

The point of __future__ is to give people a chance at using upcoming
standard features.  The __future__ enhancements are actively maintained
working code.

__past__ would mean maintaining both the old and the new standards.
Putting switches in the code to handle it right both ways and doubling
the maintenance workload.  An easier way to implement __past__ is
documentation. "If you want to do it the old way, download an old tarball"

-jackdied