I created an issue on CPython GitHub some time ago (same as the topic title here) as I thought of a current behavior as a bug.
Issue in short is: I was confused when I found out read() method of ConfigParser ignores file errors and just silently fail in the background.
Turns out, this is not that obvious of a change in behavior long term and I am looking for some opinions in the matter.
As title shows: I think when provided with an iterable of paths, it is fine for it to silently fail, but when I provide a specific file, I expect all file-related errors to propagate, not be ignored.
There is some feedback, because Configparser.read returns a list of filenames which were successfully parsed. It can be checked to see if a file was processed. OTOH you will not get the reason why it wasn’t.
There is Configparser.read_file where the caller has to open the file. This method seems to me a better choice for parsing a single file that is expected to be processed.
I agree with @xitop. Having different behavior for a single and multiple file names is errorprone. The list of files can be generated, so you can gen an unexpected exception without realising this.
As for only silencing file-not-found errors – yes, this sounds reasonable. The code was written when no OSError subclasses existed. It can silence some unexpected errors. But on other hand, ENOENT may be not the only error which you want to silence. You can get EISDIR if the path points to directory and ENOTDIR if the intermediate path points to a file. For example, if one version of you program saves settings in file “myprog/config” and other in files “myprog/config/main.ini” and “myprog/config/user.ini”, you can pass all three paths and expect that this works for all versions. In other context, they should be threated as errors.
So, if silence only specific OSError’s, we need a way to specify what errors should be silenced. It cannot just be a set of errnos, because some errors can have no errno and different errors can share the same errno and need to check also winerror on Windows. So, it should be a callable, an error handler.
I’ve run into this issue, where a PermissionError was being ignored by the ConfigParser read() call when an antivirus program was accessing the same config file to scan it. What happened in this case is that when this happened in a read/edit/write case, it would erase all the existing config properties. My PR fixing this in our codebase is fix: Improve config read robustness by mwiebe · Pull Request #803 · aws-deadline/deadline-cloud · GitHub.
I 100% agree with “I’d also say that only file-not-found errors should be silenced. Other
kinds of error should always propagate.” from Greg’s comment. If that was the behavior, the code would not have had this bug.