homepage

Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example : 
did@geru-itea:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 20051111 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
 flist = cp.get("formatters", "keys")
 File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
 raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here : 
/usr/lib/python2.3/ConfigParser.py, line 258
 for filename in filenames:
 try:
 fp = open(filename)
 except IOError:
 continue
 self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-------------------------------------------------
import os
if not (os.path.file(fname)):
 raise IOError('Provided filename is not existing')
-------------------------------------------------
Didrik

Logged In: YES 
user_id=970259
i've reported it for Python 2.4 but I reproduced it on
Python 2.3.

Logged In: YES 
user_id=970259
Oups, the patch should be the following : 
File /usr/lib/python2.3/logging/config.py, line 61
-------------------------------------------------
import os
if not (os.path.isfile(fname)):
 raise IOError('Provided filename is not existing')

Logged In: YES 
user_id=33168
Vinay, any comments?

Logged In: YES 
user_id=308438
I don't believe this is a logging bug. The logging code
defers to ConfigParser, and it is the responsibility of
ConfigParser to raise exceptions with appropriate messages.
Clearly, you could also pass an existing file with an
invalid format - the logging config code does not try to do
error recovery in these cases, but lets the exceptions
propagate up to calling code. Doing otherwise would amount
to defensive programming which I do not believe justified in
this case.
Please consider logging an issue against ConfigParser. After
all, a change there would benefit more than just the logging
package.