This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Sergey.Kirpichev
Recipients Sergey.Kirpichev, docs@python, mark.dickinson, oscarbenjamin, rhettinger, tim.peters
Date 2021-04-23.06:26:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <YIJoq+dmrd5jzluD@note>
In-reply-to <1618803509.5.0.93952714102.issue43602@roundup.psfhosted.org>
Content
Well, probably everyone else agree with Raymond.  Yet, I'll
try to clarify few things.

On Mon, Apr 19, 2021 at 03:38:29AM +0000, Raymond Hettinger wrote:
> No strong use cases have emerged that would warrant overturning
> the long-standing prior decisions on this topic.

How about other multiprecision types in external libs, i.e. mpmath.mpf
or gmpy2.mpfr?  Probably, these shouldn't be Real's as well, isn't?
In this way, the whole numbers tower above Rational class is more or
less useless, as mentioned by Oscar: Real ABC is essentially reduced to
float and Complex ABC - to complex...

Raymond, I won't object your current decision for Decimal.  But do
you think - there is no documentation issues with the numbers module,
related to Real/Complex?

The module doesn't document, for example, that R1 + R2 is expected to
work if R1 and R2 are both Reals (but different implementations).  I'm not
sure if this is a sane design decision (as this will restrict Real ABC
just to float's),  but if so - it must be documented. (comments are internal
documentation, isn't?).  It's not obvious.  (The proof e.g. is that
Decimal vs Real issue was questioned several times by different people.)
History
Date User Action Args
2021-04-23 06:26:56Sergey.Kirpichevsetrecipients: + Sergey.Kirpichev, tim.peters, rhettinger, mark.dickinson, docs@python, oscarbenjamin
2021-04-23 06:26:56Sergey.Kirpichevlinkissue43602 messages
2021-04-23 06:26:56Sergey.Kirpichevcreate