Logging module: problem with some mapping keys

[Tekkaman]

I'm getting a strange behaviour from the "pathname" and "lineno"
formatter mapping keys. Instead of my file and my line number I get:

/usr/lib/python2.4/logging/__init__.py

as the file, and 1072 as the line number. I set up my config as
follows:

logBaseConf = {
'level' : logging.DEBUG,
'format' : "%(levelname)-8s|%(asctime)s|%(pathname)s,
%(name)s, line %(lineno)s|%(message)s",
'datefmt ': '%d %b %Y, %H:%M:%S',
'filename': 'logtest.log',
'filemode': 'a'
}
logging.basicConfig(**logBaseConf)

I'm not using any executable-generating tools such as cx_Freeze or
Psyco. In fact, I'm getting this error on a very basic script with the
specific purpose of testing the logging module capabilities.

Thanks in advance for any contribution.

T.

 

[sim.sim]

Hi, i've check documentation, and found that logging.basicConfig takes
no arguments (probably we have different versions of logging package),
and i've never used it.

just try this:


fileName = 'testlog.log'
logName = 'LOG'
iHandler = logging.FileHandler(fileName)
iHandler.setFormatter(
logging.Formatter("%(levelname)-8s|%(asctime)s|%(pathname)s,%(name)s,
line %(lineno)s|%(message)s") )

iLog = logging.getLogger(logName)
iLog.addHandler(iHandler)
iLog.setLevel(logging.DEBUG)

iLog.info('hello logging')



it gives me:

INFO |2006-12-13 19:57:33,575|test.py,LOG, line 12|hello logging

 

[Peter Otten]

I'm getting a strange behaviour from the "pathname" and "lineno"
formatter mapping keys. Instead of my file and my line number I get:

/usr/lib/python2.4/logging/__init__.py

as the file, and 1072 as the line number. I set up my config as
follows:

logBaseConf = {
'level' : logging.DEBUG,
'format' : "%(levelname)-8s|%(asctime)s|%(pathname)s,
%(name)s, line %(lineno)s|%(message)s",
'datefmt ': '%d %b %Y, %H:%M:%S',
'filename': 'logtest.log',
'filemode': 'a'
}
logging.basicConfig(**logBaseConf)

I'm not using any executable-generating tools such as cx_Freeze or
Psyco. In fact, I'm getting this error on a very basic script with the
specific purpose of testing the logging module capabilities.

Thanks in advance for any contribution.

An evil symlink, maybe?

$ ln -s /usr/local/lib/python2.4/logging
$ python
[snip]$ rm logging
$ python
[snip]<stdin>

Peter

 

[Tekkaman]

Hi, i've check documentation, and found that logging.basicConfig takes
no arguments (probably we have different versions of logging package),

Your Python version is < 2.4. Now basicConfig takes optional keyword
args:

basicConfig([**kwargs])
Does basic configuration for the logging system by creating a
StreamHandler with a default Formatter and adding it to the root
logger. The functions debug(), info(), warning(), error() and
critical() will call basicConfig() automatically if no handlers are
defined for the root logger.

In my real application (not the small test script!) This behaviour is
very useful since I can call basicConfig only once in the main file and
then all I have to do in the other files is:

import logging
self.logger = logging.getLogger("myClass")

Everything works smoothly except for not being able to get file and
line number info.

 

[Tekkaman]

An evil symlink, maybe?

Thanks for the hint, but it's not a symlink

$ ln -s /usr/local/lib/python2.4/logging
$ python
[snip]$ rm logging
$ python
[snip]<stdin>

Peter

 

[Peter Otten]

Thanks for the hint, but it's not a symlink

What does logging._srcfile contain? Should be
'/usr/lib/python2.4/logging/__init__.py'

on your machine, but probably isn't.

Peter

 

[Tekkaman]

'/usr/lib64/python2.4/logging/__init__.py'

What does logging._srcfile contain? Should be

'/usr/lib/python2.4/logging/__init__.py'

on your machine, but probably isn't.

Peter

 

[Peter Otten]

'/usr/lib64/python2.4/logging/__init__.py'

And neither /usr/lib nor /usr/lib/python2.4 are symlinks?

Peter

PS: Please don't top-post

 

[Tekkaman]

lib is a symlink to lib64

And neither /usr/lib nor /usr/lib/python2.4 are symlinks?

Peter

PS: Please don't top-post

 

[Tekkaman]

And neither /usr/lib nor /usr/lib/python2.4 are symlinks?

Peter

PS: Please don't top-post

Sry for the top-post, I noticed the PS a moment too late!

 

[Peter Otten]

lib is a symlink to lib64

So my initial diagnosis was correct. Unfortunately I can no longer recommend
that you remove the symlink...

Putting /usr/lib64/python2.4 as the first entry into your

PYTHONPATH

environment variable might fix the problem (the idea is
that /usr/lib64/python2.4 precedes /usr/lib/python2.4 in sys.path and is
therefore used for the import of the logging package).

Peter

 

[Tekkaman]

So my initial diagnosis was correct. Unfortunately I can no longer recommend
that you remove the symlink...

Yes. What I really meant in my first reply was "it's not a symlink in
the script's own directory": I didn't suspect that a symlink at any
level in the path between the script and the logging module would break
findCaller().

Putting /usr/lib64/python2.4 as the first entry into your

PYTHONPATH

environment variable might fix the problem (the idea is
that /usr/lib64/python2.4 precedes /usr/lib/python2.4 in sys.path and is
therefore used for the import of the logging package).

Thanks, I'll check it out. Anyway, since this is a hack, you think this
behaviour should be reported as a bug?

Peter

T.

 

[Peter Otten]

Thanks, I'll check it out. Anyway, since this is a hack, you think this
behaviour should be reported as a bug?

Yes, that's a good idea.

Peter