improvements for the logging package
Hi, while working on something in my current project I have made several improvements to the logging package in Python, two of them are worth mentioning: 1. addition of a logging record field %(function)s, which results in the name of the entity which logged the record. My version even deduces the class name in the case which the logger is a bound method, and assuming the name of the "self" variable is indeed "self". This ability can be turned off, for performance reasons, and is useful for debugging phases. 2. log coloring formatter (useful for console output) - support for log lines like BLUE<>, etc. Now, I asked several friends of mine who program in Python often, and they told me they could use these features very much. I'm taking a risk here, that maybe someone already proposed this in this group, but I'll ask either way: Has anyone thought of posting a PEP about this? Do you think I should? I have made a great use of the logging package, and would certainly like to see it evolve and include more features. -- http://mail.python.org/mailman/listinfo/python-list
pdb in python2.5
Hi,
Maybe I'm repeating a previous post (please correct me if I am).
I've tried the following code in python 2.5 (r25:51908, Oct 6 2006,
15:22:41)
example:
from __future__ import with_statement
import threading
def f():
l = threading.Lock()
with l:
print "hello"
raise Exception("error")
print "world"
try:
f()
except:
import pdb
pdb.pm()
This fails because pdb.pm() attempts to access sys.last_traceback which
is not assigned.
Trying:
pdb.post_mortem(sys.exc_traceback)
Yields the following:
> test.py(9)f()
-> print "world"
(Pdb)
the 'w' command yields a similar output, which implies that the
exception was thrown from the wrong line.
the traceback module is better, yielding correct results (displays line
8 instead of 9).
Has anyone encountered this behavior? is pdb broken?
I get similar results for larger/more complex pieces of code.
Thanks in advance,
Rotem
--
http://mail.python.org/mailman/listinfo/python-list
Re: Possible bug in Python 2.5? (Was Re: pdb in python2.5)
Hi,
I noticed that pydb.pm() also fails in python2.5 when invoked on that
same example (seems like also trying to access a nonexistent
attribute/variable).
Is this known to you as well/was it fixed?
On Jan 25, 9:15 pm, [EMAIL PROTECTED] (R. Bernstein) wrote:
> I'd like to change my assessment of whether the problem encountered is
> a pdb bug or not. It could be a bug in Python. (Right now it is only
> known to be a bug in version 2.5.)
>
> For a given traceback t, the question is whether t.tb_frame.f_lineno
> can ever be different from t.tb_lineno.
>
> Still, for now in pydb CVS, I've worked around this by checking.
>
> [EMAIL PROTECTED] (R. Bernstein) writes:
> > "Rotem" <[EMAIL PROTECTED]> writes:
>
> > > Hi,
>
> > > Maybe I'm repeating a previous post (please correct me if I am).
>
> > > I've tried the following code in python 2.5 (r25:51908, Oct 6 2006,
> > > 15:22:41)
> > > example:
>
> > > from __future__ import with_statement
> > > import threading
>
> > > def f():
> > > l = threading.Lock()
> > > with l:
> > > print "hello"
> > > raise Exception("error")
> > > print "world"
>
> > > try:
> > > f()
> > > except:
> > >import pdb
> > >pdb.pm()
>
> > > This fails because pdb.pm() attempts to access sys.last_traceback which
> > > is not assigned.
>
> > Recent releases of pydb (http://bashdb.sf.net/pydb) don't suffer this
> > problem. (But see below.)
>
> > > Trying:
> > > pdb.post_mortem(sys.exc_traceback)
>
> > > Yields the following:
> > > > test.py(9)f()
> > > -> print "world"
> > > (Pdb)
>
> > > the 'w' command yields a similar output, which implies that the
> > > exception was thrown from the wrong line.
> > > the traceback module is better, yielding correct results (displays line
> > > 8 instead of 9).
>
> > > Has anyone encountered this behavior?
>
> > Yes, this seems to be a bug in pdb. It is using the traceback's f_line
> > instance variable rather than the tb_lineno instance variable. I guess
> > these two values are usually the same. In fact, I haven't been able to
> > come up with a Python 2.4 situtation where they are different. (If
> > someone can, I'd appreciate it if you'd send me a small example so I
> > can put it in the pydb regression tests.) Even in 2.5, it's kind of
> > hard to get a case where they are different. If I remove the "with",
> > the problem goes away.
>
> > It was also bug in pydb, but I've just committed in CVS the fix for
> > this
>
> > > is pdb broken?
>
> > Best as I can tell pdb isn't all that well maintained. (Had it been, I
> > probably wouldn't have devoted the time to pydb that I have been.)
>
> > > I get similar results for larger/more complex pieces of code.
>
> > > Thanks in advance,
>
> > > Rotem
--
http://mail.python.org/mailman/listinfo/python-list
Re: Possible bug in Python 2.5? (Was Re: pdb in python2.5)
> * comp.lang.python is not the place to file bug reports Agreed > * more detail is needed that what's been given so far Agreed. I will investigate further when I get a chance and determine if it's a problem on my end. Thanks a lot! -- http://mail.python.org/mailman/listinfo/python-list
import in execv after fork
Hello, We have been encountering several deadlocks in a threaded Python application which calls subprocess.Popen (i.e. fork()) in some of its threads. This has occurred on Python 2.4.1 on a 2.4.27 Linux kernel. Perliminary analysis of the hang shows that the child process blocks upon entering the execvp function, in which the import_lock is acquired due to the following line: def _execvpe(file, args, env=None): from errno import ENOENT, ENOTDIR ... It is known that when forking from a pthreaded application, acquisition attempts on locks which were already locked by other threads while fork() was called will deadlock. Due to these oddities I was wondering if it would be better to extract the above import line from the execvpe call, to prevent lock acquisition attempts in such cases. I'd appreciate any opinions you might have on the subject. Thanks in advance, Rotem -- http://mail.python.org/mailman/listinfo/python-list
Re: import in execv after fork
Another workaround could be re-assigning a new lock to import_lock (such a thing is done with the global interpreter lock) at PyOS_AfterFork or pthread_atfork. -- http://mail.python.org/mailman/listinfo/python-list
Memory leak involving traceback objects
Hi, I'm debugging a nasty memory leak in a framework written in Python (v2.6.2). After much digging around I found that the entire object group that is leaking is held by a frame object which is subsequently held by a traceback object. Traversing the get_referrers() of each traceback frame leads eventually to a root traceback frame which has no referrers (gc.get_referrers returns an empty list). However, this traceback object seems not to be picked by the garbage collector, and is still there even after many iterations and calls to gc.collect(). The code location to which the traceback frame points doesn't do anything special - it just catches an exception, without saving the exception itself and/or traceback anywhere. Before I dive into the Python code itself - does anyone have any idea what can cause this? Thanks, Rotem -- http://mail.python.org/mailman/listinfo/python-list
