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

Guido van Rossum guido at
Wed Jul 25 01:06:51 EDT 2001

missive at (Lee Harr) writes:

> I think this is what the PEP is proposing:
> // is current / behaviour
> / is new int/int --> fp

No, a//b would always return floor(a/b).

> 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.  The future statement doesn't have this problem -- at some
point, you're *there* and the future statement is redundant.  Of
course, the __future__ module must remember all the names of future
features, but the support everywhere else in Python can be removed.

> It would certainly make maintaining old applications that rely
> on the old behaviour much easier to port over to the new one.

Or you keep a copy of the old interpreter around.  If you are
unwilling or unable to upgrade the application, I see no reason to
switch to a different language either.

--Guido van Rossum (home page:

More information about the Python-list mailing list