[ python-Bugs-1614460 ] python-logging compatability with Zope.
Bugs item #1614460, was opened at 2006-12-13 03:02 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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 Private: No Submitted By: Simon Hookway (shookway) >Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 08:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. -- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. -- Comment By: Martin v. Löwis (loewis) Date: 2006-11-19 15:02 Message: Logged In: YES user_id=21627 Originator: NO Mailbox locking was invented precisely to support this kind of operation. Why do you complain that things break if you deliberately turn off the mechanism preventing breakage? I fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 09:06 Message: Logged In: YES user_id=11375 Originator: NO I'm testing the fix using two Python processes running mailbox.py, and my test case fails even with your patch. This is due to another bug, even in the patched version. mbox has a dictionary attribute, _toc, mapping message keys to positions in the file. flush() writes out all the messages in self._toc and constructs a new _toc with the new file offsets. It doesn't re-read the file to see if new messages were added by another process. One fix that seems to work: instead of doing 'self._toc = new_toc' after flush() has done its work, do self._toc = None. The ToC will be regenerated the next time _lookup() is called, causing a re-read of all the contents of the mbox. Inefficient, but I see no way around the necessity for doing this. It's not clear to me that my suggested fix is enough, though. Process #1 opens a mailbox, reads the ToC, and the process does something else for 5 minutes. In the meantime, process #2 adds a file to the mbox. Process #1 then adds a message to the mbox and writes it out; it never notices process #2's change. Maybe the _toc has to be regenerated every time you call lock(), because at this point you know there will be no further updates to the mbox by any other process. Any unlocked usage of _toc should also really be regenerating _toc every time, because you never know if another process has added a message... but that would be really inefficient. -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-15 08:17 Message: Logged In: YES user_id=11375 Originator: NO The attached patch adds a test case to test_mailbox.py that demonstrates the problem. No modifications to mailbox.py are needed to show data loss. Now looking at the patch... File Added: mailbox-test.patch -- Comment By: A.M. Kuchling (akuchling) Date: 2006-12-12 16:04 Message: Logged In: YES user_id=11375 Originator: NO I agree with David's analysis; this is in fact a bug. I'll try to look at the patch. -- Comment By: David Watson (baikie) Date: 2006-11-19 15:44 Message: Logged In: YES user_id=1504904 Originator: YES This is a bug. The point is that the code is subverting the protection of its own fcntl locking. I should have pointed out that Postfix was still using fcntl locking, and that should have been sufficient. (In fact, it was due to its use of fcntl locking that it chose precisely the wrong moment to deliver mail.) Dot-locking does protect against this, but not every program uses it - which is precisely the reason that the code implements fcntl locking in the first place. -- Comment By
[ python-Bugs-1616422 ] Wrong pathname value in logging output
Bugs item #1616422, was opened at 2006-12-15 15:30
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=1616422&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
Private: No
Submitted By: Tekkaman (simleo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong pathname value in logging output
Initial Comment:
When trying to log caller pathname information, instead of the actual caller's
name I get the full name of the logging module source file:
>>> import logging
>>> logging.basicConfig(format='%(pathname)s')
>>> logging.getLogger('').critical('foo')
/usr/lib/python2.4/logging/__init__.py
>>>
I've been discussing this on comp.lang.python and the suspect arised that this
has something to do with a symlink in the path leading to the module source
file (I have a lib -> lib64 symlink on my system). To verify this I copied the
entire logging directory into my home dir and retried. This is what I got:
>>> import logging
>>> logging.basicConfig(format='%(pathname)s')
>>> logging.getLogger('').critical('foo')
>>>
Additional info:
Python Version: 2.4.3
OS: Gentoo Linux 2.6.17-r8
CPU: AMD Turion(tm) 64 Mobile Technology
sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip',
'/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2',
'/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload',
'/usr/lib64/python2.4/site-packages',
'/usr/lib64/python2.4/site-packages/Numeric',
'/usr/lib64/python2.4/site-packages/dbus',
'/usr/lib64/python2.4/site-packages/gtk-2.0']
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1593751 ] poor urllib error handling
Bugs item #1593751, was opened at 2006-11-09 22:04
Message generated for change (Comment added) made by robertwinder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: poor urllib error handling
Initial Comment:
I set up a simple server that returns an empty response.
>>> from socket import *
>>> s = socket()
>>> s.bind(("", ))
>>> while 1: x, c = s.accept(); print c; x.recv(1000);
x.close()
...
Pointing urllib at this gives a traceback:
Python 2.6a0 (trunk:52099M, Oct 3 2006, 09:59:17)
[GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import urllib
>>> urllib.urlopen('http://localhost:/')
Traceback (most recent call last):
File "", line 1, in
File "/home/guido/p/Lib/urllib.py", line 82, in urlopen
return opener.open(url)
File "/home/guido/p/Lib/urllib.py", line 190, in open
return getattr(self, name)(url)
File "/home/guido/p/Lib/urllib.py", line 334, in
open_http
return self.http_error(url, fp, errcode, errmsg,
headers)
File "/home/guido/p/Lib/urllib.py", line 351, in
http_error
return self.http_error_default(url, fp, errcode,
errmsg, headers)
File "/home/guido/p/Lib/urllib.py", line 608, in
http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/home/guido/p/Lib/urllib.py", line 951, in __init__
addbase.__init__(self, fp)
File "/home/guido/p/Lib/urllib.py", line 898, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
>>>
I can repeat this with 2.2.3 and 2.4.3 as well (don't
have 2.3 around for testing).
The direct cause of the problem is that h.getfile() on
line 329 of urllib.py (in head of trunk) returns None.
--
Comment By: Robert Winder (robertwinder)
Date: 2006-12-15 17:15
Message:
Logged In: YES
user_id=195085
Originator: NO
Same error handling with 2.3. Suggested fix doesn't work and gives.
AttributeError: addinfourl instance has no attribute 'read'
--
Comment By: Robert Carr (racarr)
Date: 2006-12-05 16:26
Message:
Logged In: YES
user_id=1649655
Originator: NO
Fix?
Index: urllib.py
===
--- urllib.py (revision 52918)
+++ urllib.py (working copy)
@@ -895,8 +895,10 @@
def __init__(self, fp):
self.fp = fp
-self.read = self.fp.read
-self.readline = self.fp.readline
+ try:
+ self.read = self.fp.read
+ self.readline = self.fp.readline
+ except: print "File handler is none"
if hasattr(self.fp, "readlines"): self.readlines =
self.fp.readlines
if hasattr(self.fp, "fileno"):
self.fileno = self.fp.fileno
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1593751&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1614460 ] python-logging compatability with Zope.
Bugs item #1614460, was opened at 2006-12-13 03:02 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&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: Pending >Resolution: Fixed Priority: 5 Private: No Submitted By: Simon Hookway (shookway) Assigned to: Vinay Sajip (vsajip) Summary: python-logging compatability with Zope. Initial Comment: I'm using Zope2.8.x and python2.4. On shutdown removing the handlers causes a KeyError because the new _handlersList is not correctly updated and thus has a now non-existant handler in it. This double list/dict thing is a little cumbersome. I'm not sure either why it's a dict but i have replaced it with an OrderedDict so that old 2.3 logging behaviour works without modification. See the included patch. -- >Comment By: Vinay Sajip (vsajip) Date: 2006-12-15 17:13 Message: Logged In: YES user_id=308438 Originator: NO Yes, a fix was applied a while ago. -- Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 08:06 Message: Logged In: YES user_id=849994 Originator: NO I believe this was fixed in 2.5, but I could be mistaken. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614460&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1616422 ] Wrong pathname value in logging output
Bugs item #1616422, was opened at 2006-12-15 14:30
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&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: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Tekkaman (simleo)
>Assigned to: Vinay Sajip (vsajip)
Summary: Wrong pathname value in logging output
Initial Comment:
When trying to log caller pathname information, instead of the actual caller's
name I get the full name of the logging module source file:
>>> import logging
>>> logging.basicConfig(format='%(pathname)s')
>>> logging.getLogger('').critical('foo')
/usr/lib/python2.4/logging/__init__.py
>>>
I've been discussing this on comp.lang.python and the suspect arised that this
has something to do with a symlink in the path leading to the module source
file (I have a lib -> lib64 symlink on my system). To verify this I copied the
entire logging directory into my home dir and retried. This is what I got:
>>> import logging
>>> logging.basicConfig(format='%(pathname)s')
>>> logging.getLogger('').critical('foo')
>>>
Additional info:
Python Version: 2.4.3
OS: Gentoo Linux 2.6.17-r8
CPU: AMD Turion(tm) 64 Mobile Technology
sys.path: ['', '/usr/lib/portage/pym', '/usr/lib/python24.zip',
'/usr/lib64/python2.4', '/usr/lib64/python2.4/plat-linux2',
'/usr/lib64/python2.4/lib-tk', '/usr/lib64/python2.4/lib-dynload',
'/usr/lib64/python2.4/site-packages',
'/usr/lib64/python2.4/site-packages/Numeric',
'/usr/lib64/python2.4/site-packages/dbus',
'/usr/lib64/python2.4/site-packages/gtk-2.0']
--
>Comment By: Vinay Sajip (vsajip)
Date: 2006-12-15 17:20
Message:
Logged In: YES
user_id=308438
Originator: NO
Sorry, why is this wrong? You are making the logging call from an
interactive prompt - so you would expect to get the pathname of ,
would you not?
I get the same output on Windows where the only logging module is the one
which is part of the standard Python installation.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616422&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1616726 ] Vague description of generator close() method
Bugs item #1616726, was opened at 2006-12-15 13:09
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=1616726&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: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Lenard Lindstrom (kermode)
Assigned to: Nobody/Anonymous (nobody)
Summary: Vague description of generator close() method
Initial Comment:
In section 7 of "What's New in Python 2.5" the
subsection on the close() generator method states:
close() raises a new GeneratorExit exception
inside the generator to terminate the iteration.
On receiving this exception, the generator's code
must either raise GeneratorExit or StopIteration;
catching the exception and doing anything else is
illegal and will trigger a RuntimeError.
This suggests that if a generator raises a new exception that is neither a
GeneratorExit nor
StopIteration a RuntimeError is raised. But this
is not the case according to Part 4 of PEP 342's
"Specification Summary":
If the generator raises any other exception,
it is propagated to the caller.
The Python 2.5 interpreter is consistent with PEP 342:
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17)
[MSC v.1310 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for
more information.
>>> def raise_wrong_exception():
... try:
... yield 1
... yield 2
... except GeneratorExit:
... raise TypeError("Where is the RuntimeError?")
...
>>> i=raise_wrong_exception()
>>> i.next()
1
>>> i.close()
Traceback (most recent call last):
File "", line 1, in
File "", line 6, in raise_wrong_exception
TypeError: Where is the RuntimeError?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1616726&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1614387 ] AttributesImpl does not implement __contains__ on Linux
Bugs item #1614387, was opened at 2006-12-13 00:24 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&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: XML Group: Platform-specific Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jason Briggs (jrbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: AttributesImpl does not implement __contains__ on Linux Initial Comment: Hi there Had an odd error trying to run a utility called SVGMath: File "/home/jason/downloads/SVGMath-0.3.1/svgmath/mathconfig.py", line 54, in startElement elif u"afm" in attributes: File "/usr/lib/python2.5/site-packages/_xmlplus/sax/xmlreader.py", line 316, in __getitem__ return self._attrs[name] KeyError: 0 It appears that AttributesImpl in the sax package (xmlreader.py) doesn't implement __contains__, so the 'in' operator throws an error. This is on Kubuntu/Linux, so I'm not sure if it's distro-specific or all Linux versions of Python. In any case, if you add: def __contains__(self, name): return self._attrs.has_key(name) to AttributesImpl in xmlreader.py (as per the Windows version of Python), the problem goes away. Kind regards Jason -- >Comment By: Georg Brandl (gbrandl) Date: 2006-12-15 22:23 Message: Logged In: YES user_id=849994 Originator: NO It looks like the xmlreader.py doesn't come from the Python distribution, but from the PyXML library, which is maintained elsewhere. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1614387&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
