On 2024-10-31, Loris Bennett <loris.benn...@fu-berlin.de> wrote: > Jon Ribbens <jon+use...@unequivocal.eu> writes: >> On 2024-10-30, Loris Bennett <loris.benn...@fu-berlin.de> wrote: >>> Jon Ribbens <jon+use...@unequivocal.eu> writes: >>>> On 2024-10-30, Loris Bennett <loris.benn...@fu-berlin.de> wrote: >>>>> Jon Ribbens <jon+use...@unequivocal.eu> writes: >>>>>> As per the docs you link to, the read() method only takes filename(s) >>>>>> as arguments, if you have an already-open file you want to read then >>>>>> you should use the read_file() method instead. >>>>> >>>>> As you and others have pointed out, this is indeed covered in the docs, >>>>> so mea culpa. >>>>> >>>>> However, whereas I can see why you might want to read the config from a >>>>> dict or a string, what would be a use case in which I would want to >>>>> read from an open file rather than just reading from a file(name)? >>>> >>>> The ConfigParser module provides read(), read_file(), read_string(), >>>> and read_dict() methods. I think they were just trying to be >>>> comprehensive. It's a bit non-Pythonic really. >>> >>> OK, but is there a common situation might I be obliged to use >>> 'read_file'? I.e. is there some common case where the file name is not >>> available, only a corresponding file-like object or stream? >> >> Well, sure - any time it's not being read from a file. A bit ironic >> that the method to use in that situation is "read_file", of course. >> In my view the read() and read_file() methods have their names the >> wrong way round. But bear in mind this code is 27 years old, and >> the read() function came first. > > Yes, I suppose history has a lot to answer for :-) > > However I didn't make myself clear: I understand that there are > different functions, depending on whether I have a file name or a > stream. Nevertheless, I just can't think of a practical example where I > might just have *only* a stream, especially one containing my > configuration data. I was just interested to know if anyone can give an > example.
That was answered the first sentence of my reply. It's a bit vague because in most of the situations I can think of, one of the other read_*() methods would probably be more appropriate. But again, the history is that read_file() was added first (originally called readfp() ) so it had to handle all cases where the data being read was not coming from a named filesystem file - e.g. it's coming over a Unix socket, or an HTTP request, or from a database. It is good practice in general to provide a method that allows your class to read data as a stream, if that is appropriate for what you're doing, so that people aren't unnecessarily forced to load data fully into memory or write it to a file, as well as perhaps a convenience method thaat will read from a named file for people who are doing that. -- https://mail.python.org/mailman/listinfo/python-list
