[ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values
Bugs item #1281408, was opened at 2005-09-04 00:12
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&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: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Py_BuildValue k format units don't work with big values
Initial Comment:
Python 2.4 on Windows XP SP2
Consider this code:
unsigned long x = 0xaabbccdd;
PyObject* v = Py_BuildValue("k", x);
unsigned long y = PyLong_AsUnsignedLong(v);
y will be equal with -1 because PyLong_AsUnsignedLong
will raise an OverflowError since Py_BuildValue doesn't
create a long for the "k" format unit, but an int which
will be interpreted as a negative number.
The K format seems to have the same error,
PyLong_FromLongLong is used instead of
PyLong_FromUnsignedLongLong.
The do_mkvalue function from mod_support.c must be
fixed to use PyLong_FromUnsignedLong instead of
PyInt_FromLong for "k".
Also, the BHLkK format units for Py_BuildValue should
be documented. In my Python 2.4 manual they do not appear.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-09-18 10:59
Message:
Logged In: YES
user_id=21627
I'm not sure what it should do: the other option would be to
create an int if it fits, else a long. For 2.4.x atleast,
this would give better backwards compatibility given the
status quo.
I certainly agree that the documentation should be updated.
Patches are welcome.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-14 22:02
Message:
Logged In: YES
user_id=1188172
I think you're right. Do you too, Martin?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 12:46 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=1294453&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: George Giannakopoulos (pckid) Assigned to: Nobody/Anonymous (nobody) Summary: email.Parser.FeedParser leak Initial Comment: It seems there is a reference cycle within the FeedParser class. I discovered it while implementing a mail categorization app. It seems that the problem lies in the line: self._parse = self._parsegen().next of the FeedParser __init__ method. The object cannot be deleted and I was forced to add the line: self._parse = None in the close() method of the class just before the return call. It seems it actually corrects the situation, BUT the _parse method is no longer valid, and the object should no longer be used. If it makes any difference, the FeedParser was called by a use of the Parser class: pParser = email.Parser.Parser() mMessage = pParser.parsestr(sMessageString) del pParser -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1281408 ] Py_BuildValue k format units don't work with big values
Bugs item #1281408, was opened at 2005-09-04 00:12
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&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: Open
Resolution: None
Priority: 5
Submitted By: Adal Chiriliuc (adalx)
>Assigned to: Martin v. Löwis (loewis)
Summary: Py_BuildValue k format units don't work with big values
Initial Comment:
Python 2.4 on Windows XP SP2
Consider this code:
unsigned long x = 0xaabbccdd;
PyObject* v = Py_BuildValue("k", x);
unsigned long y = PyLong_AsUnsignedLong(v);
y will be equal with -1 because PyLong_AsUnsignedLong
will raise an OverflowError since Py_BuildValue doesn't
create a long for the "k" format unit, but an int which
will be interpreted as a negative number.
The K format seems to have the same error,
PyLong_FromLongLong is used instead of
PyLong_FromUnsignedLongLong.
The do_mkvalue function from mod_support.c must be
fixed to use PyLong_FromUnsignedLong instead of
PyInt_FromLong for "k".
Also, the BHLkK format units for Py_BuildValue should
be documented. In my Python 2.4 manual they do not appear.
--
>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-18 12:07
Message:
Logged In: YES
user_id=1188172
Attaching patch (including doc changes). For I and k, it
creates an int if it fits, else a long.
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-09-18 10:59
Message:
Logged In: YES
user_id=21627
I'm not sure what it should do: the other option would be to
create an int if it fits, else a long. For 2.4.x atleast,
this would give better backwards compatibility given the
status quo.
I certainly agree that the documentation should be updated.
Patches are welcome.
--
Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-09-14 22:02
Message:
Logged In: YES
user_id=1188172
I think you're right. Do you too, Martin?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1281408&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters
Bugs item #1293741, was opened at 2005-09-17 11:41 Message generated for change (Comment added) made by ogrisel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&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: Extension Modules Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: GRISEL (ogrisel) Assigned to: Tim Peters (tim_one) Summary: doctest runner cannot handle non-ascii characters Initial Comment: The doctest module fails when the expected result string has non-ascii charcaters even if the # -*- coding: XXX -*- line is properly set. The enclosed code sample produce the following error: Traceback (most recent call last): File "test_iso-8859-15.py", line 41, in ? _test() File "test_iso-8859-15.py", line 26, in _test tried, failed = runner.run(t) File "/usr/lib/python2.4/doctest.py", line 1376, in run return self.__run(test, compileflags, out) File "/usr/lib/python2.4/doctest.py", line 1259, in __run if check(example.want, got, self.optionflags): File "/usr/lib/python2.4/doctest.py", line 1475, in check_output if got == want: UnicodeDecodeError: 'ascii' codec can't decode byte 0xe9 in position 8: ordinal not in range(128) -- >Comment By: GRISEL (ogrisel) Date: 2005-09-18 10:25 Message: Logged In: YES user_id=795041 Unfortunateny that patch does not fix my problem. The patch at bug #1080727 fixes the problem for doctests written in external reST files (testfile and DocFileTest functions). My problem is related to internal docstring encoding (testmod for instance). However, Bjorn Tillenius says: """ If one writes doctests within documentation strings of classes and functions, it's possible to use non-ASCII characters since one can specify the encoding used in the source file. """ So according to him, docstrings' doctests with non-ascii characters should work by default. So maybe my system setup is somewhat broken. Could somebody please confirm/infirm this by running the attached sample script on his system? My system config: [EMAIL PROTECTED] (on linux) python 2.4.1 with: sys.getdefaultencoding() == 'ascii' and locale.getpreferredencoding() == 'ISO-8859-15' $ file test_iso-8859-15.py test_iso-8859-15.py: ISO-8859 English text -- Comment By: Tim Peters (tim_one) Date: 2005-09-17 17:42 Message: Logged In: YES user_id=31435 Please try the patch at http://www.python.org/sf/1080727 and report back on whether it solves your problem (attaching comments to the patch report would be most useful). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1293741&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 04:46
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&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: George Giannakopoulos (pckid)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Parser.FeedParser leak
Initial Comment:
It seems there is a reference cycle within the
FeedParser class.
I discovered it while implementing a mail
categorization app. It seems that the problem lies in
the line:
self._parse = self._parsegen().next
of the FeedParser __init__ method.
The object cannot be deleted and I was forced to add
the line:
self._parse = None
in the close() method of the class just before the
return call.
It seems it actually corrects the situation, BUT the
_parse method is no longer valid, and the object should
no longer be used.
If it makes any difference, the FeedParser was called
by a use of the Parser class:
pParser = email.Parser.Parser()
mMessage = pParser.parsestr(sMessageString)
del pParser
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 14:13
Message:
Logged In: YES
user_id=44345
Using Python built from CVS and from the 2.4
maintenance branch I executed:
s = open("... some file containing a message ...").read()
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
and let it accumulate a couple minutes of CPU time. It leaks
in the 2.4 version, but not the head (2.5) version. The two
versions of the email package appear identical (diff -ru). I
made a slightly different change. Instead of using
self._parse at all, I just replaced it with self._parsegen().next.
Memory consumption continues to grow for me.
Oddly enough, if I break out of the above loop, do a gc.collect()
and then check gc.garbage, the CVS HEAD version shows a
list of one element containing a generator. In the 2.4 release
branch version gc.garbage is empty.
Assigning to Barry as the email wiz...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 05:46
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&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: George Giannakopoulos (pckid)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Parser.FeedParser leak
Initial Comment:
It seems there is a reference cycle within the
FeedParser class.
I discovered it while implementing a mail
categorization app. It seems that the problem lies in
the line:
self._parse = self._parsegen().next
of the FeedParser __init__ method.
The object cannot be deleted and I was forced to add
the line:
self._parse = None
in the close() method of the class just before the
return call.
It seems it actually corrects the situation, BUT the
_parse method is no longer valid, and the object should
no longer be used.
If it makes any difference, the FeedParser was called
by a use of the Parser class:
pParser = email.Parser.Parser()
mMessage = pParser.parsestr(sMessageString)
del pParser
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 17:08
Message:
Logged In: YES
user_id=12800
Hmm, in Python 2.4 CVS, this always returns 0:
import gc
import email.Parser
s = open('/tmp/msg.txt').read()
try:
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
del parser
except KeyboardInterrupt:
print len(gc.garbage)
Same thing In Python 2.5 CVS. So where's the leak?
Note that it's undefined what the FeedParser does after you
call its close. It doesn't seem like a problem to set
self._parser = None in the close, if that fixes a problem,
but it's a little odd that the above program doesn't
reproduce the reported bug.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 15:13
Message:
Logged In: YES
user_id=44345
Using Python built from CVS and from the 2.4
maintenance branch I executed:
s = open("... some file containing a message ...").read()
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
and let it accumulate a couple minutes of CPU time. It leaks
in the 2.4 version, but not the head (2.5) version. The two
versions of the email package appear identical (diff -ru). I
made a slightly different change. Instead of using
self._parse at all, I just replaced it with self._parsegen().next.
Memory consumption continues to grow for me.
Oddly enough, if I break out of the above loop, do a gc.collect()
and then check gc.garbage, the CVS HEAD version shows a
list of one element containing a generator. In the 2.4 release
branch version gc.garbage is empty.
Assigning to Barry as the email wiz...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1236906 ] email.Generator traceback in forwarded msg
Bugs item #1236906, was opened at 2005-07-12 14:59
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Generator traceback in forwarded msg
Initial Comment:
The SpamBayes sb_unheader app uses the email package
to dump out a copy of a message with user-specified
headers removed. The email.Generator.Generator class is
barfing on the attached message. I haven't had a chance
to look into it yet, but I suspect it's a problem in
the email
package, not the sb_unheader program.
Here's the traceback I see. This is with a Python built
from CVS within the last couple days.
Traceback (most recent call last):
File "/Users/skip/local/bin/sb_unheader.py", line
144, in ?
main(sys.argv[1:])
File "/Users/skip/local/bin/sb_unheader.py", line
139, in main
process_mailbox(f, dosa, pats)
File "/Users/skip/local/bin/sb_unheader.py", line 86,
in process_mailbox
gen.flatten(msg, unixfrom=1)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 82, in flattenself._write(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 113, in _writeself._dispatch(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 139, in _dispatch
meth(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 273, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
File
"/Users/skip/local/lib/python2.5/email/Message.py",
line 183, in get_payload
raise TypeError('Expected list, got %s' %
type(self._payload))
TypeError: Expected list, got
montanaro:tmp% type tradelink
tradelink is aliased to `ssh -C -X loginhost.trdlnk.com'
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 17:15
Message:
Logged In: YES
user_id=12800
This program works fine for me in Python 2.4 and 2.5:
import email
data = open('/tmp/newham').read()
msg = email.message_from_string(data)
print msg
Note that getting the str of the message will flatten it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 04:46
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&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: George Giannakopoulos (pckid)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Parser.FeedParser leak
Initial Comment:
It seems there is a reference cycle within the
FeedParser class.
I discovered it while implementing a mail
categorization app. It seems that the problem lies in
the line:
self._parse = self._parsegen().next
of the FeedParser __init__ method.
The object cannot be deleted and I was forced to add
the line:
self._parse = None
in the close() method of the class just before the
return call.
It seems it actually corrects the situation, BUT the
_parse method is no longer valid, and the object should
no longer be used.
If it makes any difference, the FeedParser was called
by a use of the Parser class:
pParser = email.Parser.Parser()
mMessage = pParser.parsestr(sMessageString)
del pParser
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 16:20
Message:
Logged In: YES
user_id=44345
Try running top as the loop executes. Let it run for a couple minutes...
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 16:08
Message:
Logged In: YES
user_id=12800
Hmm, in Python 2.4 CVS, this always returns 0:
import gc
import email.Parser
s = open('/tmp/msg.txt').read()
try:
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
del parser
except KeyboardInterrupt:
print len(gc.garbage)
Same thing In Python 2.5 CVS. So where's the leak?
Note that it's undefined what the FeedParser does after you
call its close. It doesn't seem like a problem to set
self._parser = None in the close, if that fixes a problem,
but it's a little odd that the above program doesn't
reproduce the reported bug.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 14:13
Message:
Logged In: YES
user_id=44345
Using Python built from CVS and from the 2.4
maintenance branch I executed:
s = open("... some file containing a message ...").read()
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
and let it accumulate a couple minutes of CPU time. It leaks
in the 2.4 version, but not the head (2.5) version. The two
versions of the email package appear identical (diff -ru). I
made a slightly different change. Instead of using
self._parse at all, I just replaced it with self._parsegen().next.
Memory consumption continues to grow for me.
Oddly enough, if I break out of the above loop, do a gc.collect()
and then check gc.garbage, the CVS HEAD version shows a
list of one element containing a generator. In the 2.4 release
branch version gc.garbage is empty.
Assigning to Barry as the email wiz...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1236906 ] email.Generator traceback in forwarded msg
Bugs item #1236906, was opened at 2005-07-12 13:59
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&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
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Generator traceback in forwarded msg
Initial Comment:
The SpamBayes sb_unheader app uses the email package
to dump out a copy of a message with user-specified
headers removed. The email.Generator.Generator class is
barfing on the attached message. I haven't had a chance
to look into it yet, but I suspect it's a problem in
the email
package, not the sb_unheader program.
Here's the traceback I see. This is with a Python built
from CVS within the last couple days.
Traceback (most recent call last):
File "/Users/skip/local/bin/sb_unheader.py", line
144, in ?
main(sys.argv[1:])
File "/Users/skip/local/bin/sb_unheader.py", line
139, in main
process_mailbox(f, dosa, pats)
File "/Users/skip/local/bin/sb_unheader.py", line 86,
in process_mailbox
gen.flatten(msg, unixfrom=1)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 82, in flattenself._write(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 113, in _writeself._dispatch(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 139, in _dispatch
meth(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 273, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
File
"/Users/skip/local/lib/python2.5/email/Message.py",
line 183, in get_payload
raise TypeError('Expected list, got %s' %
type(self._payload))
TypeError: Expected list, got
montanaro:tmp% type tradelink
tradelink is aliased to `ssh -C -X loginhost.trdlnk.com'
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 16:31
Message:
Logged In: YES
user_id=44345
Works for me now as well. Apparently the problem's been fixed...
Close?
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 16:15
Message:
Logged In: YES
user_id=12800
This program works fine for me in Python 2.4 and 2.5:
import email
data = open('/tmp/newham').read()
msg = email.message_from_string(data)
print msg
Note that getting the str of the message will flatten it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294232 ] Error in metaclass search order
Bugs item #1294232, was opened at 2005-09-18 01:07 Message generated for change (Comment added) made by rodsenra You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&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: Type/class unification Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. -- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-09-18 23:04 Message: Logged In: YES user_id=9057 I have discussed this at length with Pedro Werneck by email. I personally believe the best path to follow is to document that the entity specified in __metaclass__ inside C class body, can be automagically replaced by the most specialized metaclass among the metaclasses associated to C ancestors. I think that will suffice for the meta-adventurous. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1236906 ] email.Generator traceback in forwarded msg
Bugs item #1236906, was opened at 2005-07-12 14:59
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&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: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Generator traceback in forwarded msg
Initial Comment:
The SpamBayes sb_unheader app uses the email package
to dump out a copy of a message with user-specified
headers removed. The email.Generator.Generator class is
barfing on the attached message. I haven't had a chance
to look into it yet, but I suspect it's a problem in
the email
package, not the sb_unheader program.
Here's the traceback I see. This is with a Python built
from CVS within the last couple days.
Traceback (most recent call last):
File "/Users/skip/local/bin/sb_unheader.py", line
144, in ?
main(sys.argv[1:])
File "/Users/skip/local/bin/sb_unheader.py", line
139, in main
process_mailbox(f, dosa, pats)
File "/Users/skip/local/bin/sb_unheader.py", line 86,
in process_mailbox
gen.flatten(msg, unixfrom=1)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 82, in flattenself._write(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 113, in _writeself._dispatch(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 139, in _dispatch
meth(msg)
File
"/Users/skip/local/lib/python2.5/email/Generator.py",
line 273, in _handle_message
g.flatten(msg.get_payload(0), unixfrom=False)
File
"/Users/skip/local/lib/python2.5/email/Message.py",
line 183, in get_payload
raise TypeError('Expected list, got %s' %
type(self._payload))
TypeError: Expected list, got
montanaro:tmp% type tradelink
tradelink is aliased to `ssh -C -X loginhost.trdlnk.com'
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 19:24
Message:
Logged In: YES
user_id=12800
I think so!
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 17:31
Message:
Logged In: YES
user_id=44345
Works for me now as well. Apparently the problem's been fixed...
Close?
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 17:15
Message:
Logged In: YES
user_id=12800
This program works fine for me in Python 2.4 and 2.5:
import email
data = open('/tmp/newham').read()
msg = email.message_from_string(data)
print msg
Note that getting the str of the message will flatten it.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1236906&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294232 ] Error in metaclass search order
Bugs item #1294232, was opened at 2005-09-18 01:07 Message generated for change (Comment added) made by pwerneck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&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: Type/class unification Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Pedro Werneck (pwerneck) Assigned to: Nobody/Anonymous (nobody) Summary: Error in metaclass search order Initial Comment: In a simple class hierarchy, I have class A with metaclass M_A and class B, subclass of A, with metaclass M_B, subclass of M_A, as required. A new class C, subclass of B, must have M_B or a subclass of it as subclass, or a TypeError, metaclass conflict exception is raised. The exception is raised in a multiple class hierarchy (diamond, trees, etc) or in a single class hierarchy when using a metaclass with no relation to M_A and M_B. If M_A or type are used as C metaclass, the interpreter is ignoring dict['__metaclass__'], which has priority over B.__class__ and using M_B, when it was supposed to raise TypeError, with the "metaclass conflict" error message. More details in attached file. -- >Comment By: Pedro Werneck (pwerneck) Date: 2005-09-19 00:42 Message: Logged In: YES user_id=696687 Yes. I think this confusion was caused because of the lack of documentation on this topic, especially on the case described here, which seems to break some rules. Since the "Unifying types and classes" essay seems to be the most used Python document about this topic and, I suggest the first rule on determining a metaclass be changed from: "If dict['__metaclass__'] exists, it is used." To something like: "If dict['__metaclass__'] exists and is equal to, or a subclass of, each of the metaclasses of the bases, it is used; if it exists and is a base class of any metaclass of the bases, the most specialized metaclass in the hierarchy is used; if it exists and doesn't satisfies any of these constraints, TypeError is raised." -- Comment By: Rodrigo Dias Arruda Senra (rodsenra) Date: 2005-09-18 23:04 Message: Logged In: YES user_id=9057 I have discussed this at length with Pedro Werneck by email. I personally believe the best path to follow is to document that the entity specified in __metaclass__ inside C class body, can be automagically replaced by the most specialized metaclass among the metaclasses associated to C ancestors. I think that will suffice for the meta-adventurous. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294232&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1284928 ] logging module's setLoggerClass not really working
Bugs item #1284928, was opened at 2005-09-08 13:51 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&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: None Status: Open Resolution: None Priority: 5 Submitted By: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. -- >Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 01:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1282539 ] logging.shutdown() not correct for chained handlers
Bugs item #1282539, was opened at 2005-09-05 21:12
Message generated for change (Comment added) made by vsajip
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fons Dijkstra (fdij)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.shutdown() not correct for chained handlers
Initial Comment:
Consider the following code:
import logging
import logging.handlers
if __name__ == "__main__":
fh = logging.handlers.RotatingFileHandler("log.txt")
mh = logging.handlers.MemoryHandler(1024,
logging.ERROR, fh)
logging.getLogger().addHandler(mh)
logging.getLogger().warning("next statement crashes")
logging.shutdown()
which results in a crash due to operating on a closed
file. The reason is that the shutdown flushes and closes
all handlers in undefined order. In above case, first
the 'fh' handlers is flushes and closed then the 'mh'
handler.
The solution is to first flush all handlers times the
number of handlers before closing them. Thus (omitting
error handling):
def shutdown():
for i in range(len(_handlers)):
for h in _handlers.keys():
h.flush()
for h in _handlers.keys():
h.close()
--
>Comment By: Vinay Sajip (vsajip)
Date: 2005-09-19 01:01
Message:
Logged In: YES
user_id=308438
Now checked into CVS.
--
Comment By: Vinay Sajip (vsajip)
Date: 2005-09-07 11:12
Message:
Logged In: YES
user_id=308438
There is indeed a problem - thanks for the report. Rather
than your proposed solution, I would rather add another
internal list, _handlerList, which holds the handlers in
*reverse* order of creation. When shutting down, (a copy of)
this list is used for the iteration rather than
_handlers.keys().
I may remove _handlers in the future - I can't remember why
I made it a dict rather than a list.
Will check into CVS soon, then mark this as Fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1282539&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 05:46
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&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: George Giannakopoulos (pckid)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Parser.FeedParser leak
Initial Comment:
It seems there is a reference cycle within the
FeedParser class.
I discovered it while implementing a mail
categorization app. It seems that the problem lies in
the line:
self._parse = self._parsegen().next
of the FeedParser __init__ method.
The object cannot be deleted and I was forced to add
the line:
self._parse = None
in the close() method of the class just before the
return call.
It seems it actually corrects the situation, BUT the
_parse method is no longer valid, and the object should
no longer be used.
If it makes any difference, the FeedParser was called
by a use of the Parser class:
pParser = email.Parser.Parser()
mMessage = pParser.parsestr(sMessageString)
del pParser
--
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 22:32
Message:
Logged In: YES
user_id=12800
Done. I never see memory usage get about 0.8% (py2.4) or
0.7% (py2.5) after running for several minutes. It
certainly doesn't appear to be leaking memory of any
detectable amount.
If it matters, I tested on Linux (Gentoo) 2.6.12 kernel.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 17:20
Message:
Logged In: YES
user_id=44345
Try running top as the loop executes. Let it run for a couple minutes...
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 17:08
Message:
Logged In: YES
user_id=12800
Hmm, in Python 2.4 CVS, this always returns 0:
import gc
import email.Parser
s = open('/tmp/msg.txt').read()
try:
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
del parser
except KeyboardInterrupt:
print len(gc.garbage)
Same thing In Python 2.5 CVS. So where's the leak?
Note that it's undefined what the FeedParser does after you
call its close. It doesn't seem like a problem to set
self._parser = None in the close, if that fixes a problem,
but it's a little odd that the above program doesn't
reproduce the reported bug.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 15:13
Message:
Logged In: YES
user_id=44345
Using Python built from CVS and from the 2.4
maintenance branch I executed:
s = open("... some file containing a message ...").read()
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
and let it accumulate a couple minutes of CPU time. It leaks
in the 2.4 version, but not the head (2.5) version. The two
versions of the email package appear identical (diff -ru). I
made a slightly different change. Instead of using
self._parse at all, I just replaced it with self._parsegen().next.
Memory consumption continues to grow for me.
Oddly enough, if I break out of the above loop, do a gc.collect()
and then check gc.garbage, the CVS HEAD version shows a
list of one element containing a generator. In the 2.4 release
branch version gc.garbage is empty.
Assigning to Barry as the email wiz...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 04:46
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&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: George Giannakopoulos (pckid)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Parser.FeedParser leak
Initial Comment:
It seems there is a reference cycle within the
FeedParser class.
I discovered it while implementing a mail
categorization app. It seems that the problem lies in
the line:
self._parse = self._parsegen().next
of the FeedParser __init__ method.
The object cannot be deleted and I was forced to add
the line:
self._parse = None
in the close() method of the class just before the
return call.
It seems it actually corrects the situation, BUT the
_parse method is no longer valid, and the object should
no longer be used.
If it makes any difference, the FeedParser was called
by a use of the Parser class:
pParser = email.Parser.Parser()
mMessage = pParser.parsestr(sMessageString)
del pParser
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 21:57
Message:
Logged In: YES
user_id=44345
Here's what I see on my Mac laptop (10.3.9) with Python 2.4.1:
montanaro:skip% ps auxww | egrep python2.4
skip10914 97.1 0.637980 6692 p8 R+9:54PM 0:15.50
python2.4
skip10926 0.0 0.018644268 std U+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 94.7 0.637980 6724 p8 R+9:54PM 0:20.75
python2.4
skip10928 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 91.7 0.637980 6748 p8 R+9:54PM 0:24.36
python2.4
skip10930 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 90.4 0.637980 6780 p8 R+9:54PM 0:29.36
python2.4
skip10932 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 75.6 0.637980 6808 p8 R+9:54PM 0:33.21
python2.4
skip10934 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 91.9 0.737980 6848 p8 R+9:54PM 0:36.86
python2.4
skip10939 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 90.0 0.737980 6928 p8 R+9:54PM 1:34.41
python2.4
skip10998 0.0 0.018644 92 std R+9:57PM 0:00.01 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 95.3 0.737980 6952 p8 R+9:54PM 1:46.65
python2.4
skip11000 0.0 0.018644 92 std R+9:57PM 0:00.00 egrep
python2.4
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 21:32
Message:
Logged In: YES
user_id=12800
Done. I never see memory usage get about 0.8% (py2.4) or
0.7% (py2.5) after running for several minutes. It
certainly doesn't appear to be leaking memory of any
detectable amount.
If it matters, I tested on Linux (Gentoo) 2.6.12 kernel.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 16:20
Message:
Logged In: YES
user_id=44345
Try running top as the loop executes. Let it run for a couple minutes...
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 16:08
Message:
Logged In: YES
user_id=12800
Hmm, in Python 2.4 CVS, this always returns 0:
import gc
import email.Parser
s = open('/tmp/msg.txt').read()
try:
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
del parser
except KeyboardInterrupt:
print len(gc.garbage)
Same thing In Python 2.5 CVS. So where's the leak?
Note that it's undefined what the FeedParser does after you
call its close. It doesn't seem like a problem to set
self._parser = None in the close, if that fixes a problem,
but it's a little odd that the above program doesn't
reproduce the reported bug.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 14:13
Message:
Logged In: YES
user_id=44345
Using Python built from CVS and from the 2.4
maintenance branch I executed:
s = open("... some file containing a message ...").read()
while True:
[ python-Bugs-1294959 ] Problems with /usr/lib64 builds.
Bugs item #1294959, was opened at 2005-09-19 03:05 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=1294959&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 Submitted By: Sean Reifschneider (jafo) Assigned to: Nobody/Anonymous (nobody) Summary: Problems with /usr/lib64 builds. Initial Comment: This is something that's becoming more and more of a problem as more people get systems that run both 32-bit and 64-bit code. There are patches (926209 858809) in the tracker to resolve this issue, I don't know exactly what state they are in. They seem fairly old, one is closed and one is still open. The Fedora RPMs include the following patches for lib64 (attached). Any thoughts on what we need to do to allow building lib64 as a part of the standard release? Or do we just want to wait for these terrible transition days to end and rely on 32+64 packagers to deal with it? Here's a short run-down of the situation: Some systems can run both 32 and 64 bit software. On these systems you *CAN* install a native 64-bit tool-chain, but some people set up both 32 and 64 bit software on these systems for compatibility. You can do 32+64 in a couple of ways, one is to set up a "chroot" environment for the secondary (typically 32-bit) set of libraries and programs. The other is to run the system with 64-bit libraries in /usr/lib64 and 32-bit in /usr/lib (because most software that needs compatibility would be running against /usr/lib, not /usr/lib32). It's a kludge to be sure, but if you need any legacy software that you do not have source for, this is a way of getting 64-bits while still retaining the ability to run 32-bit This is not a problem for systems which only run 64-bit code, nor is it a problem for these 32+64 systems which are running only 64-bit distributions on them. Thoughts? Sean -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294959&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1294453 ] email.Parser.FeedParser leak
Bugs item #1294453, was opened at 2005-09-18 04:46
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1294453&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: Closed
>Resolution: Invalid
Priority: 5
Submitted By: George Giannakopoulos (pckid)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Parser.FeedParser leak
Initial Comment:
It seems there is a reference cycle within the
FeedParser class.
I discovered it while implementing a mail
categorization app. It seems that the problem lies in
the line:
self._parse = self._parsegen().next
of the FeedParser __init__ method.
The object cannot be deleted and I was forced to add
the line:
self._parse = None
in the close() method of the class just before the
return call.
It seems it actually corrects the situation, BUT the
_parse method is no longer valid, and the object should
no longer be used.
If it makes any difference, the FeedParser was called
by a use of the Parser class:
pParser = email.Parser.Parser()
mMessage = pParser.parsestr(sMessageString)
del pParser
--
>Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 22:42
Message:
Logged In: YES
user_id=44345
*sigh* I believe I was looking at the wrong column (RSS instead of VSZ).
After running awhile I broke back to the prompt. gc.garbage is indeed
empty (as before), and running the leaks(1) command shows only the
following:
Process 11260: 3427 nodes malloced for 3353 KB
Process 11260: 2 leaks for 64 total leaked bytes.
Leak: 0x00404270 size=32 string 'COLUMNS=80'
Leak: 0x004041e0 size=32 string 'LINES=40'
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 21:57
Message:
Logged In: YES
user_id=44345
Here's what I see on my Mac laptop (10.3.9) with Python 2.4.1:
montanaro:skip% ps auxww | egrep python2.4
skip10914 97.1 0.637980 6692 p8 R+9:54PM 0:15.50
python2.4
skip10926 0.0 0.018644268 std U+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 94.7 0.637980 6724 p8 R+9:54PM 0:20.75
python2.4
skip10928 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 91.7 0.637980 6748 p8 R+9:54PM 0:24.36
python2.4
skip10930 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 90.4 0.637980 6780 p8 R+9:54PM 0:29.36
python2.4
skip10932 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 75.6 0.637980 6808 p8 R+9:54PM 0:33.21
python2.4
skip10934 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 91.9 0.737980 6848 p8 R+9:54PM 0:36.86
python2.4
skip10939 0.0 0.018644 92 std R+9:55PM 0:00.00 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 90.0 0.737980 6928 p8 R+9:54PM 1:34.41
python2.4
skip10998 0.0 0.018644 92 std R+9:57PM 0:00.01 egrep
python2.4
montanaro:skip% ps auxww | egrep python2.4
skip10914 95.3 0.737980 6952 p8 R+9:54PM 1:46.65
python2.4
skip11000 0.0 0.018644 92 std R+9:57PM 0:00.00 egrep
python2.4
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 21:32
Message:
Logged In: YES
user_id=12800
Done. I never see memory usage get about 0.8% (py2.4) or
0.7% (py2.5) after running for several minutes. It
certainly doesn't appear to be leaking memory of any
detectable amount.
If it matters, I tested on Linux (Gentoo) 2.6.12 kernel.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-09-18 16:20
Message:
Logged In: YES
user_id=44345
Try running top as the loop executes. Let it run for a couple minutes...
--
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2005-09-18 16:08
Message:
Logged In: YES
user_id=12800
Hmm, in Python 2.4 CVS, this always returns 0:
import gc
import email.Parser
s = open('/tmp/msg.txt').read()
try:
while True:
parser = email.Parser.Parser()
msg = parser.parsestr(s)
del parser
except KeyboardInterrupt:
print len(gc.garbage)
Same thing In Python 2.5 CVS.
[ python-Bugs-1284928 ] logging module's setLoggerClass not really working
Bugs item #1284928, was opened at 2005-09-08 16:51 Message generated for change (Comment added) made by rotem_ya You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&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: None Status: Open Resolution: None Priority: 5 Submitted By: Rotem Yaari (rotem_ya) Assigned to: Nobody/Anonymous (nobody) Summary: logging module's setLoggerClass not really working Initial Comment: The logging package should be modified in a way which would let users call the setLoggerClass API, and then consistently get loggers only from that class. In the logging package as it is today, the root logger will always be a logging.Logger instance, and not the new class specified in the call to setLoggerClass. These semantics are not clear. -- >Comment By: Rotem Yaari (rotem_ya) Date: 2005-09-19 09:34 Message: Logged In: YES user_id=1340892 This is an example logger class I would like to use: class PatchedLogger(logging.Logger): def __init__(self, name, *patches): logging.Logger.__init__(self, name) self.patches = patches def handle(self, record): #copied from the actual Logger implementation if (not self.disabled) and self.filter(record): for patch in self.patches: patch(record) self.callHandlers(record) And an example "patch": def EnableTrace(record): """ adds the %(function)s for logging records """ function_name = _get_function_name(inspect.stack()[4]) record.function = function_name -- Comment By: Vinay Sajip (vsajip) Date: 2005-09-19 04:00 Message: Logged In: YES user_id=308438 Can you please explain your use case? Why does the package have to be modified in that way? Why do you need to be able to have the root logger be creatable from a custom class? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1284928&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
