__past__ (Was: Re: PEP-317)

[Gerrit Holl]

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. 

JAI.

yours,
Gerrit.

-- 
184. If a man do not give a dowry to his daughter by a concubine, and
no husband; if then her father die, her brother shall give her a dowry
according to her father's wealth and secure a husband for her.
        -- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
	http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
	http://www.sp.nl/