We deliberately don't documentValueError in most cases because it's assumed to be a possibility whenever you pass in an invalid value. If we start documenting it, we'll end up having to put it on every single function.

I'd rather skip all these doc changes and keep with our usual conventions. It may be surprising at first, but the error does only occur when an invalid value is provided, and not due to OS/environment issues (which are the cause of the OSError, and we document functions that may do something that could result in an OSError because most do not).

Since OSError is already explicitly documented here, I do not see harm in mentioning also ValueError which depends on OS and environment. For example, UnicodeEncodeError (which is a subclass of ValueError) can be raised depending on the locale.

This is also important for end user to know which exceptions they should catch. OSError and ValueError are not raised in normal cases, but they can be raised depending on user data, OS and environment. It is easy to miss ValueError.

Such exceptions like TypeError, MemoryError, RecursionError should not be explicitly documented.

It depends on the OS, but not on thestate of the OS (what I meant by "environment", as opposed to "environment variables" which are only one aspect of the overall state).

ValueError can be raised practically anywhere. If you aren't sure you're passing a valid value, you always need to handle ValueError. It's in the same category as TypeError, MemoryError and RecursionError (and AttributeError when calling a function, as this is essentially the same as TypeError).

Another phrasing issue here is the switch from the imperative "is to be raised" to the descriptive "this raises". It's an abstract method definition giving instructions to subclass authors, so the "is to be raised" phrasing should be kept.

Due to that, I do think it's reasonable to mentionValueError explicitly here, specifically so subclass method implementors don't feel obliged to catch it and turn it intoOSError.

Since OSError is already explicitly documented here, I do not see harm in mentioning also ValueError which depends on OS and environment. For example, UnicodeEncodeError (which is a subclass of ValueError) can be raised depending on the locale.

This is also important for end user to know which exceptions they should catch. OSError and ValueError are not raised in normal cases, but they can be raised depending on user data, OS and environment. It is easy to miss ValueError.

Such exceptions like TypeError, MemoryError, RecursionError should not be explicitly documented.

Another phrasing issue here is the switch from the imperative "is to be raised" to the descriptive "this raises". It's an abstract method definition giving instructions to subclass authors, so the "is to be raised" phrasing should be kept.

Due to that, I do think it's reasonable to mentionValueError explicitly here, specifically so subclass method implementors don't feel obliged to catch it and turn it intoOSError.

Exceptions are covered in ResourceLoader abstract method documentation above.

Actually, I duplicated the entry because the ABC marked as deprecated since 3.7. As such, I'm not sure whether the ABC should update its documentation or not...

This change is not correct, only a lack of write permissions should be silently ignored, everything else should be propagated (despiteimportlib itself being overly broad in the errors it suppresses).

Since the tests are failing, should we also protect againstFileExistsError when writing the data? By suppressing OSError altogether, we actually suppressedFileExistsError in free-threaded builds and read-only errors (those with errno 30 but that are not explicitly PermissionError).

It seems that theFileExistsError only happens in free-threaded builds of Mac OS but I'm not sure whether it's related or not...

This should be made narrower rather than broader (i.e. only ignoringPermissionError)

Ditto on the narrower catch.