[Python-Dev] shouldn't we be considering all pending numeric proposals together?

[Guido van Rossum]

>     Guido> I think PEP 211 and PEP 242 don't belong in this list.  PEP 211
>     Guido> doesn't affect Python's number system at all, and PEP 242
>     Guido> proposes a set of storage choices, not choices in semantics.  PEP
>     Guido> 242 is valid regardless of what we decide about int division.
> 
> The inclusion of PEP 211 in this message was an oversight.  I pasted this
> list from another message.  I included PEP 242 on purpose however.  I think
> Paul gives you a language for perhaps defining other sorts of numeric
> properties besides numeric precision (which is what my reading led me to
> believe it was focused on).

Maybe, but I don't think a review of PEP 242 is necessary in order to
decide on the others.

>     ...
> 
>     Guido> But it's different the other way around: PEP 238 can easily stand
>     Guido> on its own.  It addresses a problem that exists even without a
>     Guido> unified numeric model.
> 
>     Guido> Conversely, if PEP 238 is unacceptable, PEP 228 also has no hope,
>     Guido> and PEP 239 is much less attractive.  Since PEP 238 is the only
>     Guido> one that cannot avoid breaking existing code, I want to introduce
>     Guido> it as soon as I can, since the others can only be introduced
>     Guido> after the full compatibility waiting period for PEP 238, at least
>     Guido> two years.
> 
>     ...
> 
>     Guido> If we introduce rationals, and we redefine int division as
>     Guido> returning a rational instead of a float, this will not affect the
>     Guido> mathematical value.
> 
>     ...
> 
>     Guido> I am currently maintaining the PEP 238 implementation as a patch;
>     Guido> I don't want to start any new branches before we've merged the
>     Guido> descr-branch into the trunk.
> 
> I elided a bunch of valuable information, stuff I was previously unaware of.
> The acceptability or not of PEP 238 in the broader Python community appears
> to be based on people only looking back.  As far as I know most people
> aren't aware of the long-term motivation.  (It may have been there in one of
> Guido's or Tim's messages, but if so, I missed it.)  I certainly wasn't
> aware of the motivation, and I just read the above PEPs in the past day or
> two.  Connecting all that together (a "meta PEP"?)  probably belongs in PEP
> 228.

I have Moshe's permission to co-author PEP 238, which I'll do as soon
as I'm done with my remote keynote at the O'Reilly conference (due to
circumstances beyond my control I'm not in San Diego), sometime
tomorrow.

> Here's what I propose.  Once the descr-branch has been merged, create a new
> branch, call it mouse-branch.  Add the PEP 238 and other changes there and
> update PEP 228 (last change: 4 Nov 2000) to include the rationale I deleted
> from Guido's message.  Then urge anyone with an interest in any of these
> topics to check out the mouse from CVS and play with it.  (Just don't squish
> it, that's the Python's job!)  Initially, it will just have the one change
> that has stirred up such a hornet's nest.  Still, even that will be
> instructive to play with, and in concert with a stronger motivation for the
> change in PEP 228 (and perhaps PEP 238) should help soften the blow caused
> by the change.  As I mentioned in a previous message, I think you have one
> chance to make this change.  If people perceive that "hey, he's going
> somewhere interesting with this stuff", I think they will be more open to
> the discomfort of individual changes.

That's one suggestion.  I've noticed that very few people check out
branches unless you force them.  The PEP-238 changes are localized
enough that I can maintain them as a patch in the SF patch manager;
that's easier to use for most people.

> Then, once you're ready (I don't know if 2.2 is far enough out), have the
> Python eat the mouse and start a rat-branch that incorporates all the
> rational stuff (having never used a programming language that supported
> rational numbers, I find the prospect both a bit daunting and exciting).
> That branch will live for a fairly long time, probably at least until 2.4,
> when the int division change is complete, at which point the Python can eat
> the rat.

I don't have time for rationals yet; but I do want to put phase 1 of
PEP 238 in the 2.2 release, and preferably sooner (e.g. 2.2a2) rather
than later.  Phase 1 breaks no code; all it does is add the //
operator and the future division statement.  I also plan command line
options to (1) add warnings for old-style / with int or long args; and
(2) make new-style / the default.  Both are tools (though not the only
ones) for future-proofing code.  (One goal is to make the whole
library robust under any combination of command line options; this
will require a branch or checking things in on the trunk, as it will
affect a large number of files.)

>     Guido> Have you looked at my PEP-238 patch at all?  
> 
> Not yet.  Should it be applied to the head branch or the descr-branch?

It works with either.  Also with the 2.2a1 release, I expect.

--Guido van Rossum (home page: http://www.python.org/~guido/)