[ python-Bugs-1508253 ] logging fileConfig swallows handler exception
Bugs item #1508253, was opened at 2006-06-18 14:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tdir (tdir)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging fileConfig swallows handler exception
Initial Comment:
If you specify a handler such as a RotatingFileHandler
and the path you provide in the args specification
('option') is bad, config.fileConfig() catches the
exception and 'swallows' it. The result is later on,
when that handler is specified for a logger, you get an
exception saying there is no such handler. A much
friendlier behavior would be for fileConfig() to raise
an exception so the real cause of the problem can be
easily identified. Also, if there is a bug in the code
itself, it would also get swallowed in similar fashion.
In general, silently swallowing exceptions is rarely
the best choice IMHO.
Example ini with bad path (assuming /bad/path does not
exist):
[handler_defaultrotatingfile]
class=handlers.RotatingFileHandler
args=("/bad/path/logdir/my_log.log", 'w', 10, 10)
formatter=std
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1437051 ] "continue" in .pdbrc has no effect
Bugs item #1437051, was opened at 2006-02-22 14:13 Message generated for change (Comment added) made by isandler You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437051&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Coolheads Consulting (coolheads) Assigned to: Nobody/Anonymous (nobody) Summary: "continue" in .pdbrc has no effect Initial Comment: I'm using Python 2.4.2 under Debian Woody; uname -a: Linux bruno 2.4.23 i686 GNU/Linux The documentation for pdb says that commands in .pdbrc will be executed just as if they were typed in at the pdb prompt. However, "c", "cont", and "continue" have no effect. It would be nice if this would work. I discovered this problem because I need to be able to call Python scripts from within a Makefile, and it is convenient, when one of them goes awry (say, because of a key error exception), to already be in the debugger when such exceptions are raised. However, I can't call a Python script with the debugger from a makefile because execution always stops at the beginning of the script, waiting for a "continue" to be typed in at the prompt. I thought I could solve the problem with a "continue" in the .pdbrc in the local directory. However, every way I can think of to say "continue", including aliasing it, has no effect in the .pdbrc. Is there another way to accomplish what I'm trying to do? Steve Newcomb [EMAIL PROTECTED] -- Comment By: Ilya Sandler (isandler) Date: 2006-06-18 14:09 Message: Logged In: YES user_id=971153 The problem is limited to step/next/continue... "l", "break", etc do work. As far as I can tell the following is happening 1. .pdbrc is read (but not executed!) on pdb startup 2. it's executed when pdb first time enters the interaction() 3. if rc file contains, "continue", then do_continue() IS executed but it has no effect, because pdb's interaction() does not return and simply proceeds with user's input.. (do_continue()/do_next()/do_step() work by setting up a stopping condition and returning to interpreter) The problem can be fixed by having execRcLines check every command's return status and returning as soon as any command returns 1.. Of course, the rest of rclines would need to be executed later... For the record, gdb's .gdbinit files do allow commands like "run"/"continue"/etc If there is any interest in this fix, I can submit a patch -- Comment By: Terry J. Reedy (tjreedy) Date: 2006-03-05 18:00 Message: Logged In: YES user_id=593130 I wonder whether the .pdbrc is being read and executed when you think it is. Is the problem actually specific to 'continue'? If you put 'list' in the file, do you get a listing? It might help if you gave the exact command line you use to start the Python script. I don't know if this is really a bug. You might get answers about 'another way' on python- list/comp.lang.python. (I don't know ;-) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1437051&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1506776 ] Misleading error message from PyObject_GenericSetAttr
Bugs item #1506776, was opened at 2006-06-15 16:24 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506776&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Alexander Belopolsky (belopolsky) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading error message from PyObject_GenericSetAttr Initial Comment: When an extension type Foo defines tp_getattr, but leaves tp_setattr NULL, an attempt to set an attribute bar results in an AttributeError with the message "'Foo' object has no attribute 'bar'". This message is misleading because the object may have the attribute 'bar' as implemented in tp_getattr. It would be better to change the message to "'Foo' object has only read-only attributes (assign to .bar)" as in the case tp_setattro == tp_setattr == NULL in PyObject_SetAttr . I've also noticed that the exceptions raised from PyObject_SetAttr are TypeErrors. Shouldn't PyObject_GenericSetAttr raise a TypeError if tp_setattr is null but tp_getattr is not? This would be consistent with the errors from read-only descriptors. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-06-18 22:19 Message: Logged In: YES user_id=849994 Unfortunately the message "object has only readonly attrs" isn't quite right either, since there may be other attributes that can be set and deleted. I tried to come up with a better message but couldn't find one. The exception type cannot be changed for sure, because of backwards compatibility. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1506776&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508369 ] logging module formatter problem with %(filename)s
Bugs item #1508369, was opened at 2006-06-18 21:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Macintosh Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: David Hess (david_k_hess) Assigned to: Jack Jansen (jackjansen) Summary: logging module formatter problem with %(filename)s Initial Comment: With Python 2.4.3 installed via the .dmg on to MacOS, when the python modules are compiled, they are compiled by specifying the path in such a way that it contains a double slash. This causes the logging module to not be able to figure out which module is the correct one to replace for % (filename)s. The following is the crux of the issue: >>> logging.debug.func_code.co_filename '/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/ logging/__init__.py' >>> logging.__file__ '/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/ logging/__init__.pyc' >>> These two strings need to match for %(filename)s to work. I deleted /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/logging/__init__.pyc and recompiled it by just importing logging. That fixed the problem. I assume the fix will be in the installer somewhere. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508369&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1497962 ] Leak in tarfile.py
Bugs item #1497962, was opened at 05/30/06 23:42
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jens Jørgen Mortensen (jensj)
Assigned to: Nobody/Anonymous (nobody)
Summary: Leak in tarfile.py
Initial Comment:
There is a leak when using the tarfile module and the
extractfile method. Here is a simple example:
$ echo "grrr" > x.txt
$ tar cf x.tar x.txt
$ python
Python 2.4.2 (#2, Sep 30 2005, 21:19:01)
[GCC 4.0.2 20050808 (prerelease) (Ubuntu
4.0.1-4ubuntu8)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import gc
>>> import tarfile
>>> tar = tarfile.open('x.tar', 'r')
>>> f = tar.extractfile('x.txt')
>>> f.read()
'grrr\n'
>>> del f
>>> gc.set_debug(gc.DEBUG_LEAK)
>>> print gc.collect()
gc: collectable
gc: collectable
gc: collectable
3
>>> print gc.garbage
[, {'name':
'x.txt', 'read': >, 'pos':
0L, 'fileobj': , 'mode': 'r', 'closed': False, 'offset':
512L, 'linebuffer': '', 'size': 5L}, >]
>>>
--
>Comment By: SourceForge Robot (sf-robot)
Date: 06/18/06 19:21
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Tim Peters (tim_one)
Date: 06/01/06 16:09
Message:
Logged In: YES
user_id=31435
There's no evidence of a leak here -- quite the contrary.
As the docs say, DEBUG_LEAK implies DEBUG_SAVEALL, and
DEBUG_SAVEALL results in _all_ cyclic trash getting
appended to gc.garbage. If you don't mess with
gc.set_debug(), you'll discover that gc.garbage is empty at
the end.
In addition, note that the DEBUG_LEAK output plainly says:
gc: collectable ...
That's also telling you that it found collectable cyclic
trash (which it would have reclaimed had you not forced it
to get appended to gc.garbage instead). If gc had found
uncollectable cycles, these msgs would have started with
gc: uncollectable ...
instead.
Most directly, if I run your tarfile open() and file
extraction in an infinite loop (without messing with
gc.set_debug()), the process memory use does not grow over time.
Unless you have other evidence of an actual leak, this
report should be closed without action. Yes, there are
reference cycles here, but they're of kinds cyclic gc reclaims.
--
Comment By: Jens Jørgen Mortensen (jensj)
Date: 06/01/06 13:08
Message:
Logged In: YES
user_id=716463
Problem is that the ExfileObject hat an attribute
(self.read) that is a method bound to itself
(self._readsparse or self._readnormal). One solution is to
add "del self.read" to the close method, but someone might
forget to close the object and still get the leak. Another
solution is to change the end of __init__ to:
if tarinfo.issparse():
self.sparse = tarinfo.sparse
else:
self.sparse = None
and add a read method:
def read(self, size=None):
if self.sparse is None:
return self._readnormal(size)
else:
return self._readsparse(size)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1497962&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1508253 ] logging fileConfig swallows handler exception
Bugs item #1508253, was opened at 2006-06-18 12:33
Message generated for change (Settings changed) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: tdir (tdir)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging fileConfig swallows handler exception
Initial Comment:
If you specify a handler such as a RotatingFileHandler
and the path you provide in the args specification
('option') is bad, config.fileConfig() catches the
exception and 'swallows' it. The result is later on,
when that handler is specified for a logger, you get an
exception saying there is no such handler. A much
friendlier behavior would be for fileConfig() to raise
an exception so the real cause of the problem can be
easily identified. Also, if there is a bug in the code
itself, it would also get swallowed in similar fashion.
In general, silently swallowing exceptions is rarely
the best choice IMHO.
Example ini with bad path (assuming /bad/path does not
exist):
[handler_defaultrotatingfile]
class=handlers.RotatingFileHandler
args=("/bad/path/logdir/my_log.log", 'w', 10, 10)
formatter=std
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1508253&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
