[issue2898] Add memory footprint query
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: I propose a patch which allows to query the memory footprint of an object. Calling 'footprint(o)', a python developer can retrieve the size of any python object. Only the size of the object itself will be returned, the size of any referenced objects will be ignored. The patch implements a generic function to compute the object size. This works in most, but a few cases. One of these exceptions is the dictionary with its particular table implementation. Such cases can be handled by implementing an optional method in C. This would also be the case for third-party implementations with unusual type definitions. One advantage with this approach is that the object size can be computed at the level an object is allocated, not requiring complex computations and considerations on higher levels. I am not completely happy with the name 'footprint', but think using 'sizeof' would be confused with plain 'size', and 'memory_usage' was somewhat too long to be typed conveniently. Current test pass on linux32 and linux64, but the test suite is not complete, yet. This patch is part of my Google Summer of Code project on Python memory profiling (http://code.google.com/soc/2008/psf/appinfo.html?csaid=13F0E9C8B6E064EF). Also, this is my first patch, so please let me know where missed something, did not follow coding conventions, or made wrong assumptions. -- components: Interpreter Core files: footprint.patch keywords: patch messages: 66989 nosy: okkoto severity: normal status: open title: Add memory footprint query type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file10353/footprint.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: > Can't you write this as a simple Python function using > type.__basicsize__ and type.__itemsize__? Yes, it would be possible and has been done, e.g. http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/546530. The problem is though, that it requires handling of all special cases externally. Any changes need to be addressed separately and unknown type definitions cannot be addressed at all. Also I figured the programmer implementing a type would know best about its size. Another point is different architectures which result in different object sizes. > In any case, if this is added somewhere it should not be a builtin. What place would you consider to be appropriate? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I tried to implement a magic method __sizeof__() for the type object which should be callable for type objects and type itself. But calling __sizeof__ results in an error message >>> type.__sizeof__() Traceback (most recent call last): File "", line 1, in TypeError: descriptor '__sizeof__' of 'type' object needs an argument Debugging it I found that type_getattro will (1) look for the attribute in the metatype, (2) look in tp_dict of this type, and (3) use the descriptor from the metatype. I actually want it to perform (3), but since type is its own metatype (2) will be triggered. This then results in the need for an argument. The same behavior occurs for all type instances, i.e. classes. Is my understanding correct? How would it be possible to invoke __sizeof__() on the type 'type' and not on the object 'type'? My first approach did the same for object, that is a magic __sizeof__() method linked to object, but it gets ignored when invoked on classes or types. Now from my understanding everything is an object, thus also classes and types. isinstance seems to agree with me >>> >>> isinstance(int, object) True Any suggestions on that? thanks, robert ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: thanks, that did the trick. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: The attached patch implements the sizeof functionality as a sys module function. __sizeof__ is implemented by object as a instance method, by type as a class method as well as by types which's size cannot be computed from basicsize, itemsize and ob_size. sys.getsizeof() has some work-arounds to deal with type instances and old-style classes. Added file: http://bugs.python.org/file10463/sizeof.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Changes by Robert Schuppenies <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file10463/sizeof.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Nick Coghlan helped me to clear my 'metaclass confusion' so here is a patch without an additional __sizeof__ for type objects. Added file: http://bugs.python.org/file10465/sizeof.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Applied in r63856. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2898> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3049] Some 3k sizeof tests fail
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r63985. -- status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Are they any buildbots running with the "--enable-unicode=ucs4" option? Just curious. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3048] getsizeof incorrect for Unicode strings
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r64066. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3048> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Changes by Robert Schuppenies <[EMAIL PROTECTED]>: -- keywords: +patch Added file: http://bugs.python.org/file10623/maxunicode.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: sys.maxunicode is well defined to be either 0x for UCS-2 or 0x10 for UCS-4 (see PyUnicode_GetMax). Py_UNICODE_SIZE is set in pyconfig.h to be either 2 or 4 during configuration. When >= 4, Py_UNICODE_WIDE is set which again influences sys.maxunicode. Thus, it currently is possible to derive Py_UNICODE_SIZE from sys.maxunicode. But it takes some indirections. So here are 2 possible patches, one which exposes Py_UNICODE_SIZE via _testcapi and one which assumes that sys.maxunicode reflects UCS-X settings. Since I am a fairly new Python developer and the new 4-eyes-per-commit policy for the beta phase, please decide which patch should be applied. Added file: http://bugs.python.org/file10624/Py_UNICODE.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
I think you're right that sizeof(Py_UNICODE) is the correct value to
use. But could you please explain to me how PY_UNICODE_TYPE is set, I
cannot find it.
Also, len(u'\0'.encode('unicode-internal')) does not work for Py3.0.
Any suggestion how could this information can be retrieved in py3k?
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3098>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Found it, thanks. Wrong use of grep :| ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: If I understand configure correctly, PY_UNICODE_TYPE is only set when a type matching the size of $unicode_size is found. And this is set to either 2 or 4. Thus, sizeof(Py_UNICODE) should always return 2 or 4. If you agree, I would suggest using the method proposed by Marc in msg68179. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Correct is good, so here is a patch which exposes the size of Py_UNICODE via _testcapi. Added file: http://bugs.python.org/file10635/Py_UNICODE_SIZEOF.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
New submission from Robert Schuppenies <[EMAIL PROTECTED]>:
>>> import re
>>> import sys
>>> r = re.compile('')
>>> sys.getsizeof(r)
Traceback (most recent call last):
File "", line 1, in
AttributeError: __sizeof__
This applies to objects of the types _sre.SRE_Pattern,
_sre.SRE_Scanner, and _sre.SRE_Match.
The attached patch addresses this issue.
--
assignee: schuppenies
components: Interpreter Core
files: _sre_sizeof.patch
keywords: patch, patch
messages: 68266
nosy: schuppenies
severity: normal
status: open
title: sys.getsizeof() gives an AttributeError for _sre objects.
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10639/_sre_sizeof.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3122>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3130] In some UCS4 builds, sizeof(Py_UNICODE) could end up being more than 4.
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: This issue is a branch from issue3098. Below a summary of the discussion: Antoine Pitrou wrote: > It seems that in some UCS4 builds, sizeof(Py_UNICODE) could end > up being more than 4 if the native int type is itself larger than 32 > bits; although the latter is probably quite rare (64-bit platforms are > usually either LP64 or LLP64). Marc-Andre Lemburg wrote: > AFAIK, only Crays have this problem, but apart from that: I'd consider > it a bug if sizeof(Py_UCS4) != 4. Antoine Pitrou wrote: > Perhaps a #error can be added to that effect? > Something like (untested): > > #if SIZEOF_INT == 4 > typedef unsigned int Py_UCS4; > #elif SIZEOF_LONG == 4 > typedef unsigned long Py_UCS4; > #else > #error Could not find a 4-byte integer type for Py_UCS4, aborting > #endif Marc-Andre Lemburg wrote: > Sounds good ! > > Python should really try to use uint32_t as fallback solution for > UCS4 where available (and uint16_t for UCS2). > > We'd have to add an AC_TYPE_INT32_T and AC_TYPE_INT16_T check to > configure: > > http://www.gnu.org/software/autoconf/manual/html_node/Particular-Types.html#Particular-Types > > and could then use > > typedef uint32_t Py_UCS4 > > and > > typedef uint16_t Py_UCS2 > > Note that the code for supporting UCS2/UCS4 is not really all that > clean. It was a quick sprint between Martin and Fredrik and appears > to be only half-done... e.g. there currently is no Py_UCS2. -- components: Unicode messages: 68310 nosy: schuppenies severity: normal status: open title: In some UCS4 builds, sizeof(Py_UNICODE) could end up being more than 4. type: behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3098] sys.sizeof test fails with wide unicode
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I followed Marc's advise and checked-in a corrected test. Besides, I opened a new issue to address the fallback solution for UCS4 and UCS2 (see issue3130). -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3098> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2898] Add memory footprint query
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Jean Brouwers wrote:
> 1) In the first line of function dict_sizeof()
> + res = sizeof(PyDictObject) + sizeof(mp->ma_table);
> is the sizeof(mp->ma_table) counted twice?
Yes, you are right. I'll fix this.
> 2) Since functions list_sizeof and dict_sizeof return the allocated
> size, including the over-allocation, should function string_sizeof not
> include the sentinel null character?
Isn't this addressed by taking PyStringObject.ob_sval into account? It
is allocated with 1 char length and thus always included. If I
understand the creation of strings correctly, the corresponding memory
is always allocated with
PyObject_MALLOC(sizeof(PyStringObject) + size)
which should mean that the space for the null terminating character is
included in the sizeof(PyStringObject).
>
>
> 3) Are tuples left out on purpose?
No, that slipped the initial patch. I corrected in r64230.
>
> static PyObject *
> tuple_sizeof(PyTupleObject *v)
> {
> Py_ssize_t res;
>
> res = _PyObject_SIZE(&PyTuple_Type) + Py_SIZE(v) *
> sizeof(void*);
> return PyInt_FromSsize_t(res);
> }
>
Your implementation is like the applied changes from me, with one
difference. The basicsize of a tuple is defined as
"sizeof(PyTupleObject) - sizeof(PyObject *)"
When a tuple's memory is allocated, the required space is computed
roughly like this
(typeobj)->tp_basicsize + (nitems)*(typeobj)->tp_itemsize
Thus, I understand the memory allocated by a tuple to be
res = PyTuple_Type.tp_basicsize + Py_SIZE(v) * sizeof(PyObject *);
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2898>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3147] tests for sys.getsizeof fail on win64
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: The tests still do not pass on the AMD64 W2k8. Surprisingly, struct.calcsize behaves as expected, but sizeof() on the C level does not. The former seems to assumes long to be 4 byte in size, the latter 8! The tests pass until it comes to a situation where the size of long affects the alignment of the structure end. In this case long and function. long's structure is 'lP PP l H' which gives an expected size of 8+8+16+4+2(+2) = 40 At least this how I think it should be and struct.calcsize does, too. But what seems to be computed is 8+8+16+8+2(+6) = 48. It appears as if sizeof(long) = 8. The same explanation holds true for the failure on the function size which is 'lp PP 9l' and struct.calcsize : 8+8+16+36(+4) = 72 sizeof : 8+8+16+72 = 104 Now I don't know how I should address this problem. It seems to be Windows AMD64 specific, but I found a post [1] which indicates that it's Windows AMD64 on Windows 2K specific. Tests do also fail on the Win64 XP buildbot, but it gets killed before the verbose output is generated. I don't have access to such a platform, so I cannot verify it. It may also be a problem with struct.calcsize on Win64. Any suggestions? [1] http://www.velocityreviews.com/forums/t491385-different-behavior-of-amd64-compiler-14004031041-on-windows-xp-and-2k.html -- nosy: +loewis ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: What would be a good way to identify *all* possible types? When I started, I included all objects in /Objects, but obviously this is not sufficient. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: The attribute error is caused by pattern_getattr, which tries to find __sizeof__, fails and then sets the error message. I don't know if casting the error is the right thing to do. Actually, sys.getsizeof() should work on any type. Another suggestion was a that sys.getsizeof allows one optional argument for a default size. If the default argument is provided, sys.getsizeof will not throw an exception (if the __sizeof__ method is missing or for any other error), but instead return the given default size. Still, an agreement on the right error message is needed. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: You are right, the rule is to not include referenced objects. But, and this has been rather informal up to now, I handled transparently cached information as something that is added to the memory used by an object (see unicode.defenc). The same I applied to MatchObject.regs. The rational being that the user cannot know wether the match positions are cached or not. What do you think? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I was refering to the fact that something on the C level is cached without the Python user ever noticing that it wasn't there before. Caching itself is no criteria, but allocating memory without giving the user a chance to find out should be (in this context). Maybe I am missing something here, but calling match.regs creates a tuple which is not there before, but cannot be removed afterwards. This is why I handled it separately. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Okay, I get the point. With including unicode.defenc I already included a referenced object which was ruled out in the first place. And this for a good reason. What bugs me, though, is that this leaves out a potentially significant amount of memory. I know that this is already the case for shared objects (e.g. the above mentioned numbers) or malloc overhead, but adding yet another exception bothers me. On the other hand, since it's hidden behind the C API, I don't know how to address this problem. Maybe just give it some text in the documentation is sufficient. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3147] tests for sys.getsizeof fail on win64
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r64533. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3147> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Amaury, I was testing your patch and it turns out, that it will ignore any __sizeof__ attribute which may be available through getattr. I adapted it a bit, so now getsizeof will try to call the method on the passed object first, and if it fails or the object is a type, the code proposed by you will be executed. This also deals with old-style class instances. The match_sizeof function in the patch is just to showcase the example. What do you think? Added file: http://bugs.python.org/file10802/sizeof2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3122] sys.getsizeof() gives an AttributeError for _sre objects.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r64842. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3391] Idle uses old showwarning signature
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: Idle does not use the 'line' argument for its showwarning function. This results in the DeprecationWarning "functions overriding warnings.showwarning() must support the 'line' argument", or, when called from within Idle "TypeError: idle_formatwarning_subproc() takes exactly 4 arguments (5 given)". The error can be reproduced from within Idle as well as demonstrated with verify.py. The attached patch applies the behavior of the default warnings implementation. -- components: IDLE files: idle.patch keywords: patch messages: 69879 nosy: brett.cannon, schuppenies priority: normal severity: normal status: open title: Idle uses old showwarning signature type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file10926/idle.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3391] Idle uses old showwarning signature
Changes by Robert Schuppenies <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file10927/verify.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3391> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: The problem does still exist (Python 2.6b2). I attached a patch for Tkinter.py which addresses this problem. It is the same as in the first proposed fix, but adds an additional check whether the menu item has a 'command' property. I also removed the "INDEX2 (is included)" comment, as it is not the desired behavior (see http://www.tcl.tk/man/tcl8.5/TkCmd/text.htm#M98). I cannot confirm the behavior, but it should be a separate issue nevertheless. -- keywords: +patch nosy: +schuppenies Added file: http://bugs.python.org/file11025/tkinter_menuleak.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3498] mod_cls
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: Using sphinx I get the following error if I want to document methods via automethod: reading sources... copyright glossary [..] refbrowser Exception occurred: File "[..]/doctools/sphinx/ext/autodoc.py", line 313, in resolve_name if not mod_cls: UnboundLocalError: local variable 'mod_cls' referenced before assignment. [..] I am not familiar with the code base, but from the comments the attached patch should address the issue. -- assignee: georg.brandl components: Documentation tools (Sphinx) files: mod_cls.patch keywords: patch messages: 70697 nosy: georg.brandl, schuppenies severity: normal status: open title: mod_cls type: behavior Added file: http://bugs.python.org/file11057/mod_cls.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3498> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3528] TypeError when compiling with no translator
New submission from Robert Schuppenies <[EMAIL PROTECTED]>:
I just ran 'make html' with the latest version and got this exception:
loading translations [en]... Exception occurred:
File "/home/bob/data/dvl/python/svn/doctools/sphinx/builder.py", line
184, in load_i18n
self.info('selected locale not available' % self.config.language)
TypeError: not all arguments converted during string f
The enclosed patch fixes the issue.
--
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: str_formatting.patch
keywords: patch
messages: 70901
nosy: georg.brandl, schuppenies
severity: normal
status: open
title: TypeError when compiling with no translator
type: behavior
Added file: http://bugs.python.org/file11087/str_formatting.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3528>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r65622. Backported to the release25-maint and merged into the py3k branch. -- resolution: accepted -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3546] Missing linebreak in ext.doctest output
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: There is a linebreak missing in the doctest extension. See attached patch. -- assignee: georg.brandl components: Documentation tools (Sphinx) files: linebreak.patch keywords: patch messages: 71053 nosy: georg.brandl, schuppenies severity: normal status: open title: Missing linebreak in ext.doctest output type: behavior Added file: http://bugs.python.org/file11102/linebreak.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3546> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: You are right. How about the attached patch, do you see any problems here? Tkinter seems to ignore any delete calls when either of the indices is None, so the deletion of commands may be ignored as well. But I couldn't find a description making this API behavior official. And does anybody know about a test suite for the Tkinter library where issues like these are tested? Added file: http://bugs.python.org/file11146/tkinter_menu-error.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I was thinking about returning in that new if statement, too, but decided not too. The reason is that I didn't want to anticipate _tkinter implementations, which may change (although not likely, still possible). Also, with the third beta tomorrow, I am not sure if somebody will find the time to approve the patch in time. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I am sry that you see it that way, I do not. I was given commit access solely for gsoc purposes and committing changes before a late release without review from a committer IMHO violates strict policies. I tried to get somebody to review the patch twice on the #python-dev channel, but was ignored. Maybe I should have made more fuss about it. Also, since it is still a beta, it is not the end of the world. I don't like it either but take the blame now. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1342811] Tkinter.Menu.delete doesn't delete command of entry
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r65971. Backported to the release25-maint and merged into the py3k branch. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1342811> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3680] Cycles with some iterator are leaking.
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: The dict, set, and deque iterators do not implement tp_traverse although they reference container objects. This can lead to reference cycles which will not be collected. The attached cycle.py script from Amaury demonstrates the problem for dict iterators. The attached patch addresses the issue for the above mentioned types. The method applied in the demonstration script was used for test cases. This is my first excursion into cyclic garbage collector implementations, so please review carefully. Also, I am not sure about tp_traverse for the deque type. Must the block member also be considered or is the deque member sufficient? Finally, do you consider this a show stopper? -- components: Interpreter Core files: cycle.py keywords: patch messages: 71955 nosy: amaury.forgeotdarc, schuppenies severity: normal status: open title: Cycles with some iterator are leaking. versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11254/cycle.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3680] Cycles with some iterator are leaking.
Changes by Robert Schuppenies <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file11255/tp_traverse.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3690] sys.getsizeof wrong for Py3k bool objects
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: sys.getsizeof returns wrong results for bool objects in Python 3000. Although bool objects use the same datatype as long objects, they are allocated differently. Thus, the inherited long_sizeof implementation is incorrect. The applied patch addresses this issue. -- components: Interpreter Core files: bool_sizeof.patch keywords: patch messages: 71996 nosy: schuppenies severity: normal status: open title: sys.getsizeof wrong for Py3k bool objects type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file11264/bool_sizeof.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3859] test_sys.Sizeof fails on win64
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: You are right, it should be '3P'. When merging to py3k I changed the previous line, but not the one causing trouble. -- keywords: +patch Added file: http://bugs.python.org/file11486/test_sys.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3690] sys.getsizeof wrong for Py3k bool objects
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: As I understood the long object allocation it is implemented as "PyObject_MALLOC(sizeof(PyVarObject) + size*sizeof(digit))" to avoid this allocation of extra 2 bytes. So from my understanding, the number 0 allocates memory for the reference count, type, and ob_size, whereas any other number allocates this plus additional memory required by the number of digits. Looking at bool objects in Py3k, arn't they fixed-sized memory-wise, always allocating the the padded size of _longobject? > In any case, I also think this doesn't matter much either way. Why do you think so? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3680] Cycles with some iterator are leaking.
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: > I think it's ok, since the underlying containers will get cleared, thus > breaking the cycle. What about the dictiter object which references a tuple (di_result)? Tuple does not implement tp_clear, but OTOH tuples are immutable and di_result cannot be assigned. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3690] sys.getsizeof wrong for Py3k bool objects
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: > What's the actual difference that this change makes? It would provide more accurate results, even in the light of being not perfect. > [..] each small_int takes a complete PyLongObject. If that was also > considered in long_sizeof, the computation would happen to be > completely correct for bool also. So how should this bug report be handled? Provide a patch to handle getsizeof correctly for small_ints? 'wont fix' because there are issues anyway? I would prefer the former and try to come up with a patch if you think it is worthwhile. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3859] test_sys.Sizeof fails on win64
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Fixed in r66480. -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3859> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3934] sphinx - building muppy docs fails on Linux
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: This was fixed in r65489 (see issue3498). Using the current Sphinx trunk (http://svn.python.org/projects/doctools/trunk/sphinx) works for me. -- resolution: -> duplicate status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3934> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3690] sys.getsizeof wrong for Py3k bool objects
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: Attached is a patch which takes the preallocation of small_ints into account. What do you think? Added file: http://bugs.python.org/file11568/smallints_sizeof.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue687648] classic division in demos/ directory
Robert Schuppenies added the comment: The attached patch applies floor division to all classic divisions where only integer input was used, and true division where at least on input parameter was of non-integral type. In cmptree.py I replaced "int(size/dt)" with "size//dt" as it has the same semantic but I thought it to be more explicit. -- keywords: +patch nosy: +okkoto Added file: http://bugs.python.org/file9585/demo_classicdivision.diff Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue687648> ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2227] time.strptime too strict? should it assume current year?
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Applying the _strptime.diff patch broke the _strptime
test("test_defaults"). Once you change the year, you also have to adapt
the day of week, as this becomes dynamic, too. The rest remains the
same, though. I attached a patch to this test which tests for the
new-years day of the current year instead of 1900, but I feel like
changing the semantic of the default value is no minor change. Also, I
am not sure what the documentation should say then.
--
nosy: +okkoto
Added file: http://bugs.python.org/file9800/test_strptime.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2227>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1517495] memory leak threading or socketserver module
Robert Schuppenies <[EMAIL PROTECTED]> added the comment: I can *not* confirm the leak. I tested using the provided scripts (with little modifications to log memory usage), using 1000 instead of 20 runs. I am running on Debian Linux and checked the reported Python 2.4.2 and the current trunk (2.6a2). I attached my results for both. For me it looks like the average memory variations. -- nosy: +okkoto Added file: http://bugs.python.org/file9941/memory2.4.2.csv _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1517495> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1517495] memory leak threading or socketserver module
Changes by Robert Schuppenies <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9942/memory2.6a2.csv _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1517495> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4435] Sphinx does not show failed doctests in quiet mode
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: Sphinx does not show failed doctests when run in quiet mode. Any output from the tests seems to be suppressed. The same applies to the linkckeck builder. -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 76455 nosy: georg.brandl, schuppenies severity: normal status: open title: Sphinx does not show failed doctests in quiet mode type: behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4435> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4436] Sphinx latex writer crashes when encountering deep section levels
New submission from Robert Schuppenies <[EMAIL PROTECTED]>: The Sphinx latex writer crashes if a documentation has more than 7 levels in a section hierarchy. The LaTeXTranslator class defines 7 section names, each corresponding to a level. If a deeper level is encountered, no appropriate section name can be found: File "[..]/svn/doctools/sphinx/latexwriter.py", line 348, in visit_title print "self.sectionnames", self.sectionnames[self.sectionlevel] IndexError: list index out of range -- assignee: georg.brandl components: Documentation tools (Sphinx) messages: 76456 nosy: georg.brandl, schuppenies severity: normal status: open title: Sphinx latex writer crashes when encountering deep section levels type: behavior ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4436> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4833] Explicit directories for zipfiles
New submission from Robert Schuppenies :
We have an issue with the Python cheeseshop which is probably an issue
with Python itself as well.
When we create a zip file with standard linux tools ('zip os-zipped.zip
*'), uploading it works fine. But if we use the zipfile module from
Python and try to upload the result to the cheeseshop, we get this error
message:
" Error unpacking zipfile:[Errno 2] No such file or directory:
u'/data/packagedocs/Pympler/_sources/index.txt'"
Turns out that the Python-zipped version does not include explicit
directories. The OS-zipped version contains "directory/,
directory/asizeof.txt", the Python-zipped file only
"directory/asizeof.txt". Digging deeper, Python has no way to explicitly
add directories to a zip file.
It would be useful to have an option which allows the explicit creation
of directories inside of zip files. This would help when working with
applications which do not create directories if they are not explicitly
specified.
--
components: Library (Lib)
messages: 79070
nosy: schuppenies
severity: normal
status: open
title: Explicit directories for zipfiles
type: feature request
___
Python tracker
<http://bugs.python.org/issue4833>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.
Changes by Robert Schuppenies : -- nosy: +schuppenies ___ Python tracker <http://bugs.python.org/issue4258> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
New submission from Robert Schuppenies : Running this code: >>> import weakref >>> class C: pass ... >>> ws = weakref.WeakSet([C]) >>> if ws == 1: ... print(1) ... gives me the following exception: Traceback (most recent call last): File "", line 1, in File "/home/bob/python/svn/py3k/Lib/_weakrefset.py", line 121, in __eq__ return self.data == set(ref(item) for item in other) TypeError: 'int' object is not iterable Looking at _weakrefset.py line 121 gives def __eq__(self, other): return self.data == set(ref(item) for item in other) which treats any 'other' object as a set like object. Therefore comparing WeakSet to a non-set-like object always fails. Do I understand it correctly and if so, is this the intended behavior? -- components: Library (Lib) messages: 87420 nosy: schuppenies severity: normal status: open title: WeakSet cmp methods type: behavior versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment: Here is a patch which will return False instead of TypeError. This is the same behavior a normal set has. Two things though. 1. I don't know wether the 'import _abcoll' statement somehow influences the bootstrap in one way or the other, because 'from _abcoll import Iterable' does. 2. The current WeakSet implementation returns True if a WeakSet is compared to any Iterable which contains the same set of objects: >>> import weakref >>> >>> class Foo: pass ... >>> l = [Foo(), Foo(), Foo()] >>> ws = weakref.WeakSet(l) >>> ws == l True Not sure wether this is intended, since this is not the same behavior of a normal set. If it is intended, I think it should be documented. -- keywords: +needs review, patch Added file: http://bugs.python.org/file13955/_weakrefset.patch ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment:
Sounds right to me. Here is another patch plus tests.
Going through the other tests, I adapted two more tests to actually test
WeakSet. Also, I found the following one and think it is a copy&paste
from test_set which is not useful for test_weakset. Should it be removed
(as currently done in the patch)?
def test_set_literal(self):
s = set([1,2,3])
t = {1,2,3}
self.assertEqual(s, t)
--
Added file: http://bugs.python.org/file13957/_weakrefset.patch
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Changes by Robert Schuppenies : Removed file: http://bugs.python.org/file13955/_weakrefset.patch ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Changes by Robert Schuppenies : -- stage: needs patch -> patch review ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment: The test passes on my machine, but a quick review would definitely be nice :) -- ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment: If that is the right behavior then yes. Is this documented somewhere? -- ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment: I am now a bit confused about the semantics of __eq__ for WeakSets. Is a WeakSet only equal to another WeakSet with the same elements or to any iterable with the same elements, e.g. list? Because this is how I read the current implementation. If it is the latter, when should a NotImplementedError be raised? Whenever the other object is not an Iterable? -- ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment: Maybe because I take the doc too specfic. It says "A rich comparison method may return the singleton NotImplemented if it does not implement the operation for a given pair of arguments." I see the type check of the 'other' object as an operation towards the equal comparison, since it validates wether 'self' and 'other' can be equal at all. If they are of a different type, then they cannot be equal, thus the anwser to "Are 'self' and 'other' equal?" should be False. This again, would mean an equal operation is implemented and returning NotImplemented is not the right anwser. But going through similar code snippets shows otherwise, so my understanding must be lacking something. Therefore here is patch which returns NotImplemented. -- Added file: http://bugs.python.org/file13989/_weakrefset-notimplemented.patch ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5964] WeakSet cmp methods
Robert Schuppenies added the comment: Fixed in r72751. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue5964> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
