GeezerVison

cc @Yhg1s

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.