Repository navigation
_decimal and _pydecimal compatibility differences #117056
Description
Bug report
Bug description:
There are two backends for the decimal module, one from libmpdec (_decimal) and the other being a native re-implementation in Python (_pydecimal).
The signatures of methods like Decimal.__add__ take a named context argument when imported from _pydecimal, but cannot accept that argument when imported from _decimal.
mpdecimal is not bundled with Python installations on all platforms, and my understanding is that there are even more changes to how it's packaged incoming as per #115119. The difference between the two backends has caused cross-platform incompatibility for at least one project, and I'd argue it's very difficult for anyone who encounters this problem to understand the issue because the error messages mention nothing about an external dependency being required.
Would it be possible to remove the context argument from the _pydecimal backend, or to add it to the _decimal backend even if it's unused, to resolve the incompatibility?
CPython versions tested on:
3.11
Operating systems tested on:
Linux
Activity
serhiy-storchaka commentedon Mar 20, 2024
It is other way: the Python implementation accepts and passes the
contextargument to some special methods, while the C implementation has standard signatures.The implementation is not designed for overloading these special methods in subclasses. Perhaps it would be better to implement the logic of addition in other method (e.g.
_add()) or global function which accepts thecontextargument, and call it in__add__(),__sub__(), and other methods. It still not guarantee that Decimal subclasses with overloaded special methods work the same in both implementations, but it is closer to the C implementation.cc @mdickinson
antonok-edm commentedon Mar 20, 2024
Ah, right, I managed to get it backwards 😅
Updated the original post.
rhettinger commentedon Mar 23, 2024
FWIW the extra context parameter was considered an implementation detail from the outset. It was not a documented part of the public API. In practice this was worked out well and proven harmless. The users likely never see it because arithmetic dunder methods aren't typically called directly (the
+operator is more convenient and it supports the fallback to__radd__).I recommend leaving this as-is. There isn't anything worth churning all this long stable code. The referenced issue in the
rp2project is rather exotic and not typically for a user of the decimal module.If anything, I would suggest adding a note to the docs acknowledging the implementation detail.
This would be a lot of code churn for almost no benefit. It would make the module even harder to read and maintain. Also, in the pure python verion, and extra layer of function call forwarding would just may the module slower.
pythongh-117056: fix discrepancy in _decimal/_pydecimal public signat…
skirpichev commentedon Aug 18, 2025
I did an attempt to sync signatures in #137697 and it seems that core devs accept this only partially.
I'm closing this based on Raymond's opinion.