Re: Using 'with open(...) as ...' together with configparser.ConfigParser.read

On 2024-10-31, Loris Bennett <loris.bennett@fu-berlin.de> wrote:

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

On 2024-10-30, Loris Bennett <loris.bennett@fu-berlin.de> wrote:

Jon Ribbens <jon+usenet@unequivocal.eu> writes:

On 2024-10-30, Loris Bennett <loris.bennett@fu-berlin.de> wrote:

Jon Ribbens <jon+usenet@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.