from __past__ import integerDivision (was Re: A modest PEP0238 suggestion)

[Bruce Sass]

On Thu, 26 Jul 2001, Chris Gonnerman wrote:
> From: "Guido van Rossum" <guido at python.org>
> > missive at frontiernet.net (Lee Harr) writes:
> > > we already have people importing things from the __future__,
> > > how difficult would it be to let people drag things from the __past__?
> >
> > This has been suggested before.  It's just as easy (in fact in a sense
> > it's easier, since you know what the past was, but you may be wrong
> > about what the future might bring :-).  But the problem (as I see it)
> > is that there will never be a point where we can throw away support
> > for the past behavior, because there will always be code around that
> > imports it.
>
> I disagree here... in fact I think this is a *plus*.  That is, when version
> 3.0 comes out (for instance) and the code says "from __past__ import
> division"
> then you get an exception.  This is GOOD... obvious code breakage is much
> safer than silent code breakage.  You get notified right away, when the new
> version compiles the code, that this bird don't fly no more.

Hmmm, I was thinking __past__ would be available in a couple of
releases after __future__ became unnecessary, then disappear.
Intended only as an easy way for someone experiencing a bug in an old
program to quickly check if it is caused by a new feature.

Using __past__ would be a hack, and the clearest warning you can get
that a program is going to break in the near future.

> My proposal for
>
>     from __numerics__ import original
>
> is the same sort of thing.  When the "original" semantics disappear, the
> user gets an obvious error message.

__future__ and __past__ both imply reference to some specific time,
and it is reasonable to expect what they are being used for will go
away when that time becomes inconsequential to the present (i.e., the
future has already come, or the past is distant).

__<something specific>__ has no such transitory implications, and
would best be left for permanent features.  Perhaps for sets of
incompatible features that must all be in the language.


- Bruce