[Python-Dev] [Python-3000] Rounding Decimals

[Guido van Rossum]

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/)