[Python-Dev] [Python-3000] Rounding Decimals (original) (raw)

Guido van Rossum guido at python.org
Mon Jan 14 19:39:00 CET 2008

On Jan 14, 2008 5:48 AM, Jim Jewett <jimjjewett at gmail.com> wrote:

On 1/12/08, Guido van Rossum <guido at python.org> wrote: > On Jan 12, 2008 5:09 PM, Jeffrey Yasskin <jyasskin at gmail.com> wrote: > > During the discussion about the new Rational implementation > > (http://bugs.python.org/issue1682), Guido and Raymond decided that > > Decimal should not implement the new Real ABC from PEP 3141. So I've > > closed http://bugs.python.org/issue1623 and won't be pursuing any of > > the extra rounding methods mentioned on this thread.

> Well, I didn't really decide anything. I suggested that if the > developers of Decimal preferred it, it might be better if Decimal did > not implement the Real ABC, and Raymond said he indeed preferred it. I read his objections slightly differently. He is very clear that Decimal itself should be restricted to the standard, and therefore should not natively implement the extensions.

Well, to me that sounds like idolizing the standard. The standard exists so as to ensure that decimal numbers have well-understood semantics that are implemented correctly. I don't think the standard was ever meant to exclude optimal interaction with the rest of a language. I'd like to see if ReXX implements numeric features over and above the standard.

But he also said that it might be reasonable for another package to subset or superset it in a friendlier way.

From a user's perspective, it might make more sense to move the strictly standard-conforming code into a module "decimal_standard" and make the friendlier-named "decimal" module be that friendly superset.

numbers.py is a different module, which must be explicitly imported.

If the objection is that >>> decimal.Decimal("43.2").imag would work (instead of throwing an exception) only when numbers.py has already been imported, then ... well, that confusion is inherent in the abstract classes.

Fortunately, the confusion is in your mind only, because that's not how ABCs work according to PEP 3119. While as a side effect of importing the numbers module, the Decimal class might become a virtual subclass of numbers.Real, that doesn't mean that implementation features are automatically added. The registration that might take place inside numbers.py only affects the outcome of isinstance() and issubclass() checks -- it doesn't magically add missing attributes or methods to the class.

Or is the problem that it still wouldn't work, without help from the decimal module itself?

Right.

In that case, 3rd party registration is fairly limited, and this might be a good candidate for trying to figure out ABCs and adapters should work together.

Of course 3rd party registration is limited -- there's no way that you could automatically define the right semantics, since the ABCs don't have a way to express semantics.

PEP 3119 is meant as a first step towards adopting ABCs as a core feature. The changes added to collections.py and numbers.py are best considered as minimal examples. The main achievement of the PEP is probably the hooks that allow you to override isinstance() and issubclass(), plus the decision (which was discussed at length) to use ABCs (with virtual inheritance), not interfaces, to model similarities between class APIs.

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

More information about the Python-Dev mailing list