__past__ (Was: Re: PEP-317)
gerrit at nl.linux.org
Wed Jun 11 21:16:33 CEST 2003
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
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.
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:
Het zijn tijden om je zelf met politiek te bemoeien:
More information about the Python-list