extend methods of decimal module

Chris Angelico rosuav at gmail.com
Fri Feb 28 10:36:07 EST 2014


On Sat, Mar 1, 2014 at 2:11 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
>> or there needs to be a system for constructing literals
>> of non-built-in types. And if Decimal becomes built-in, then why that
>> and not <<insert type name here>>?
>
> 'Cos we have ten fingers and in count in decimal :-P

We talk in words and characters, so we have an inbuilt Unicode type.
We count in decimal using Arabic numerals, so we have an inbuilt
Decimal type. We also learn, in grade school, to manipulate vulgar
fractions, so should Fraction be inbuilt? And we use transcendental
numbers, too. And ordered mappings - most real-world interpretations
of "dictionary" include that it's sorted alphabetically. Not all of
them need to be inbuilt.

>> Also, if Decimal becomes a built-in type, does that affect the numeric
>> tower?
>
> I don't see why whether the type is built-in or not should affect its
> position in the numeric tower. (I would expect that by the time Python
> 4000 comes around, Decimal will be nicely integrated in the tower.)

Well, it's more important if it's the default (and asking for an
explicit float if you want it), but it would still be a bit odd for
just one of the built-in numeric types to not have a place in an
otherwise-tidy tower. But definitely, if it's the default, we have to
ask: what about complex numbers? Are they now two Decimals? Can we get
complex floats? And does all this mean there's a massive duplication
going on? What happens if you sum() a Decimal, a float, a Decimal
complex, and a float complex? What's the resulting type? All these
questions would have to be answered.

That said, though, I would support the addition of a Decimal literal,
and start encouraging its use. Python startup performance is a cost,
but maybe the cost of Decimal could be either reduced or deferred till
first use, so that's not so obvious. Being able to tell people "Just
type 0.1d and it'll be more accurate at the expense of being slower"
would be a significant gain.

But someone else can champion that PEP :)

ChrisA



More information about the Python-list mailing list