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,
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
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 r
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
thanks, that did the trick.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2898>
___
_
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 fro
Changes by Robert Schuppenies <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10463/sizeof.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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
__
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Applied in r63856.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Fixed in r63985.
--
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.py
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://
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Fixed in r64066.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
Changes by Robert Schuppenies <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file10623/maxunicode.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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 wh
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'
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Found it, thanks. Wrong use of grep :|
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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
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
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 t
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 la
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:
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 th
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 co
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 PROTECTE
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
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.
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
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
signi
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Fixed in r64533.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
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
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Fixed in r64842.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
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, whe
Changes by Robert Schuppenies <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file10927/verify.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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'
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,
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_i1
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 PR
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.
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
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
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
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 PR
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 p
Changes by Robert Schuppenies <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file11255/tp_traverse.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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 a
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/file1148
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
allocate
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
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
> consi
Robert Schuppenies <[EMAIL PROTECTED]> added the comment:
Fixed in r66480.
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs
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
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 &
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"
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
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
Changes by Robert Schuppenies <[EMAIL PROTECTED]>:
Added file: http://bugs.python.org/file9942/memory2.6a2.csv
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.o
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 (
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 s
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
Pyth
Changes by Robert Schuppenies :
--
nosy: +schuppenies
___
Python tracker
<http://bugs.python.org/issue4258>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 "&quo
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
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. Sh
Changes by Robert Schuppenies :
Removed file: http://bugs.python.org/file13955/_weakrefset.patch
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bug
Changes by Robert Schuppenies :
--
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bugs-list mai
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/issue5
Robert Schuppenies added the comment:
If that is the right behavior then yes. Is this documented somewhere?
--
___
Python tracker
<http://bugs.python.org/issue5
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
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
Robert Schuppenies added the comment:
Fixed in r72751.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue5964>
___
___
Python-bugs-lis
69 matches
Mail list logo
