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

Bruce Sass bsass at freenet.edmonton.ab.ca
Thu Jul 26 13:12:09 EDT 2001


On Thu, 26 Jul 2001, Chris Gonnerman wrote:
<...>
> The "original" semantics under my proposal would be "invented" as already
> deprecated, and would be removed in 3.0 as the current plan stands.  We
> have deprecated and subsequently removed things before without the
> __future__ directives and it didn't kill us; hence I see the question of
> "transitory implications" as only of minor concern.  Remember, explicit
> (even in documentation) is better than implicit.

I'm not sure then, why "original" would be needed if it will be
removed when 3.0 comes out.  My understanding is that the original
semantics will be available until 3.0, without any additional work.
Or maybe they will be available via an option only, for the release
just before 3.0.

If you can convince the `powers that be' that the original semantics
should be retained as an incompatible option, then "from __numeric__
import ..." would seem to be a reasonable course of action.  Ditto if
you want rationals, etc., to be an option instead of builtin;
although a plain "import rationals" would look nicer.

However, if you are after an alternative to an ugly command line
switch... then let's convince Guido that the __past__ need not stick
around forever, because at some point the past becomes so distant as
to have no direct bearing on the present and can safely be ignored).
Guido gets to play god and decide when the __past__ is distant enough
to have support for it dropped.


- Bruce

p.s. - Explicit documentation is no good if it doesn't get read, and
while we can't do anything about those who don't read all the
pertinent docs, we can at least not lead them into thinking that a
transitory feature will stick around because we have implemented it in
such a way as to imply it may be permanent.





More information about the Python-list mailing list