Author r.david.murray
Recipients Michał Szymaniak, SilentGhost, maxking, r.david.murray, terry.reedy
Date 2019-11-24.18:34:01
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1574620442.35.0.566417371273.issue38672@roundup.psfhosted.org>
In-reply-to
Content
I haven't looked at this in detail, but here are my general thoughts: I think it would be reasonable to expect that the module would function even if the file permissions are screwed up, similar to how unix commands that try to read .netrc will (try to) function even if its permissions are wrong.  I would, however, expect the module to emit a warning in that case.  I'm of two minds about the behavior when the caller specifies filenames explicitly.  I could see that going either way, but I lean slightly toward making the behavior consistent.  While the programmer might appreciate the traceback, the user of the program would probably appreciate the "try to keep going" behavior, since the filenames provided will often be in the same class of "standard defaults" as the existing well known files are, just in the context of that particular application.  But like I said, that is just a lean, and I could go the other way on this as well :)

I haven't looked at the isflie issue, but it seems reasonable that if the path exists we should make sure it is a file before reading it...but perhaps readfp will effectively do that?  Write a test and see what happens :)

I don't know whether to call this change a bug fix or a feature, so I guess we'd default to feature unless someone can tilt the balance with an argument :)
History
Date User Action Args
2019-11-24 18:34:02r.david.murraysetrecipients: + r.david.murray, terry.reedy, SilentGhost, maxking, Michał Szymaniak
2019-11-24 18:34:02r.david.murraysetmessageid: <1574620442.35.0.566417371273.issue38672@roundup.psfhosted.org>
2019-11-24 18:34:02r.david.murraylinkissue38672 messages
2019-11-24 18:34:01r.david.murraycreate