[issue5964] WeakSet cmp methods

Robert Schuppenies robert.schuppen...@gmail.com added the comment: Fixed in r72751. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5964

[issue5964] WeakSet cmp methods

Robert Schuppenies robert.schuppen...@gmail.com 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

[issue5964] WeakSet cmp methods

Robert Schuppenies robert.schuppen...@gmail.com added the comment: The test passes on my machine, but a quick review would definitely be nice :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5964

[issue5964] WeakSet cmp methods

Robert Schuppenies robert.schuppen...@gmail.com added the comment: If that is the right behavior then yes. Is this documented somewhere? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5964

[issue5964] WeakSet cmp methods

Changes by Robert Schuppenies robert.schuppen...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5964

[issue5964] WeakSet cmp methods

Robert Schuppenies robert.schuppen...@gmail.com 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 copypaste from test_set which

[issue5964] WeakSet cmp methods

Changes by Robert Schuppenies robert.schuppen...@gmail.com: Removed file: http://bugs.python.org/file13955/_weakrefset.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5964

[issue5964] WeakSet cmp methods

Robert Schuppenies robert.schuppen...@gmail.com 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

[issue5964] WeakSet cmp methods

New submission from Robert Schuppenies robert.schuppen...@gmail.com: 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 stdin, line 1, in module

[issue4258] Use 30-bit digits instead of 15-bit digits for Python integers.

Changes by Robert Schuppenies robert.schuppen...@gmail.com: -- nosy: +schuppenies ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4258

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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] 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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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 stdin, line 1, in module AttributeError: __sizeof__ This applies to objects of the types _sre.SRE_Pattern, _sre.SRE_Scanner

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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