[Python-Dev] PEP for adding a decimal type to Python

Guido van Rossum guido@zope.com
Thu, 26 Jul 2001 18:21:31 -0400

> This was a proposal for a mechanism for mingling types safely.  It
> was not intended as a definition of how decimal numbers should be
> implemented.  My implementation tests the interaction of the current
> number types with the decimal type and I only completed enought of
> the decimal type implementation to support this testing.  I was not
> expecting to discuss how decimal types should work.  That has been
> discussed already. I was primarily interested in testing the effects
> of adding a new number type as I described in the PEP.

Can you summarize the rules you used for mixed arithmetic?  I forget
what your PEP said would happen when you add a decimal 1 to a binary
1.  Is the result decimal 2 or binary 2?  Why?

> What did you think of the idea of adding a new command and file format?

I don't think that would be necessary.  I'd prefer the 'd' and 'f' (or
maybe 'b'?) suffixes to be explicit, perhaps combined with an optional
per-module directive to set the default.  This would be more robust
than keying on the filename extension.  If you have to change the
default globally, I'd prefer a command line option.  After all it's
only the scanner that needs to know about the different defaults,

I wonder about the effectiveness of the default though.  If you write
a module for decimal arithmetic, how do you prevent a caller to pass
in a binary number?

> > Are you aware that Aahz is implementing "the real" spec for
> > Python, a level up at
> >
> >     http://www2.hursley.ibm.com/decimal/
> >
> > under "Base specification"?  There are so few people working on
> > the decimal idea that I hate to see it fragmented already.
> Yes I have played with the Decimal.py module. I developed
> decimalobject.c so I could test the inpact of introducing an
> additional command and file format to Python.  I expect this code to
> be replaced.  As I said in the PEP I also think the decimal number
> implementation will evolve into a type that supports inheritance.

Please, please, please, unify all these efforts.  A decimal PEP would
be a good one, but there should be only one.

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