In #122081, the NEWS entry would be better if we had those documented features (as an RST entry, decimal.IEEEContext is already documented at the function level). I can work a PR now (@skirpichev, do you want to do it since you're more familiar with those features? (though I don't mind doing it if you don't have time))
I'm not sure if we should do this right now. There is a pr, that exposes this functional as public: #122003; it adds also docs.
There is a need to decide fate of this stuff in the decimal module. This is not tested with regular CI tests or with build bots, now we also have crash report #122081.
I'm not aware of it. I just think we shouldn't actually document something that crashes. So it's better to first fix the crash, document a feature that exists and is provided to the user via EXTRA_FUNCTIONALITY and decide whether this should be kept behind that flag or not.
Actually, what I find weird is that we do not document EXTRA_FUNCTIONALITY at all but still add documentation to IEEEContext as if they could be public (which I think it should be considered as such if we use EXTRA_FUNCTIONALITY). But I can't find any mention of EXTRA_FUNCTIONALITY in the docs (or even in the configure help).
I just think we shouldn't actually document something that crashes.
My doubts mostly about order of later points.
I find weird is that we do not document EXTRA_FUNCTIONALITY at all but still add documentation to IEEEContext
I would guess one was undocumented intentionally. But if you wish to document this option - it has a lot of stuff beyond just IEEEContext support. And all that (?) is missing in _pydecimal.
I think we should document something from that camp only if that will became enabled per default and ported to python's module.
Activity
skirpichev commented on Aug 18, 2024
I'm not sure if we should do this right now. There is a pr, that exposes this functional as public: #122003; it adds also docs.
There is a need to decide fate of this stuff in the decimal module. This is not tested with regular CI tests or with build bots, now we also have crash report #122081.
picnixz commented on Aug 18, 2024
Mmh. Now that I think about, how about this order:
skirpichev commented on Aug 18, 2024
Is there another similar case in stdlib?
picnixz commented on Aug 18, 2024
I'm not aware of it. I just think we shouldn't actually document something that crashes. So it's better to first fix the crash, document a feature that exists and is provided to the user via EXTRA_FUNCTIONALITY and decide whether this should be kept behind that flag or not.
Actually, what I find weird is that we do not document EXTRA_FUNCTIONALITY at all but still add documentation to IEEEContext as if they could be public (which I think it should be considered as such if we use EXTRA_FUNCTIONALITY). But I can't find any mention of EXTRA_FUNCTIONALITY in the docs (or even in the configure help).
skirpichev commented on Aug 18, 2024
My doubts mostly about order of later points.
I would guess one was undocumented intentionally. But if you wish to document this option - it has a lot of stuff beyond just IEEEContext support. And all that (?) is missing in _pydecimal.
I think we should document something from that camp only if that will became enabled per default and ported to python's module.
picnixz commented on Aug 18, 2024
AH! Ok, it makes sense now. I'll close the issue for now.