gh-141510: Use frozendict for errno.errorcode#144906
gh-141510: Use frozendict for errno.errorcode#144906vstinner wants to merge 1 commit intopython:mainfrom
Conversation
|
cc @Yhg1s |
| add_errcode("ENOTCAPABLE", ENOTCAPABLE, "Capabilities insufficient"); | ||
| #endif | ||
|
|
||
| PyObject *frozendict = PyFrozenDict_New(error_dict); |
There was a problem hiding this comment.
I think that we have to add new C API for frozendict with builder pattern.
This is inefficient for many people.
There was a problem hiding this comment.
Well, frozendict is not widely used in C code yet. IMO it's too early to design an optimized API to build a new frozendict object. PyFrozenDict_New() should be good for now.
|
What's the rationale for using frozendict here? I don't think it's unreasonable at all for user/library code to want to add to errno.errorcode. We build the module contents from compile time constants, but we don't add any once the Python version is released. It's not at all unreasonable to want to add known errno values on older Python versions, or adding ones that weren't supported by the build environment. |
|
Ah ok, in this case, I close my PR. My rationale is that I wanted to disallow modifying existing error codes or adding new error codes. But you say that it's possible on purpose, so I prefer to close the PR. |
|
Just to be clear: I'm not saying it's possible on purpose, just that I think it is a useful property even if it wasn't on purpose, and I do think we have to consider that people are using the mutability. That's the case for any existing, exposed dict: it may not make sense to mutate it, but maybe we just don't see the cases where it does make sense. We have to consider whether the change is worth the potential breakage, so I think we need a good, real-world reason to replace the dict with a frozendict, not just a theoretical, common-sense one. |
📚 Documentation preview 📚: https://cpython-previews--144906.org.readthedocs.build/