Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file26588/stringio_sizeof-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file26587/stringio_sizeof-3.2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file26810/stringio_sizeof-3.3_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file26586/stringio_sizeof-3.3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file26811/stringio_sizeof-3.2_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file26812/stringio_sizeof-2.7_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Alexandre Vassalotti alexan...@peadrop.com:
Removed file: http://bugs.python.org/file27241/stringio_sizeof-3.2_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Changes by Hynek Schlawack h...@ox.cx:
--
nosy: -hynek
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Python-bugs-list mailing list
Changes by Serhiy Storchaka storch...@gmail.com:
--
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Serhiy Storchaka added the comment:
Patches updated. Now the computations done in size_t.
Note that the patches for the different versions differ.
--
Added file: http://bugs.python.org/file27240/stringio_sizeof-3.3_3.patch
___
Python tracker
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file27241/stringio_sizeof-3.2_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file27242/stringio_sizeof-2.7_3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Martin v. Löwis added the comment:
I disagree that sizeof cannot work well for variable-sized types. It works very
well for strings, lists, tuple, dicts, and other regular containers. I agree
that it is not important that it is absolutely correct (in some sense) for
every object, but it
Serhiy Storchaka added the comment:
It can't work well if we count internal Python objects that can be shared. This
is because the work well concept is not well defined. And because the
implementation of a certain defined calculation algorithm can be completely
unmaintainable, that is not
Martin v. Löwis added the comment:
Am 17.09.2012 14:26, schrieb Serhiy Storchaka:
I would personally prefer if the computations where done in
Py_ssize_t, not PyObject*
I too. But on platforms with 64-bit pointers and 32-bit sizes we can
allocate total more than PY_SIZE_MAX bytes (hey, I
Serhiy Storchaka added the comment:
It would be good if someone looked at the patches. I'm not sure that they are
good enough. Perhaps they are too complicated and we shouldn't worry about
duplicates?
--
___
Python tracker rep...@bugs.python.org
Antoine Pitrou added the comment:
Well, I do think that it's not very important to make __sizeof__ strictly exact
according to some specification. I'm also not sure we want to complicate
maintenance when the calculation becomes tedious or difficult.
To me __sizeof__ is mostly an educational
Changes by Aaron Iles aaron.i...@gmail.com:
--
nosy: +aliles
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Python-bugs-list mailing
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: storchaka -
keywords: +needs review
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Serhiy Storchaka added the comment:
Patch updated. Now private pyobjects (readnl, accu) counted.
Note all three patches rather different.
--
Added file: http://bugs.python.org/file26810/stringio_sizeof-3.3_2.patch
___
Python tracker
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file26811/stringio_sizeof-3.2_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file26812/stringio_sizeof-2.7_2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
assignee: - storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Serhiy Storchaka added the comment:
Do I understand correctly that for each Python subobject must be one of the
following:
1) or it is visited in tp_traverse;
2) or it is accounted in __sizeof__ together with all its subobjects (if they
cannot leak out)?
PyAccu can contains not only Unicode
Antoine Pitrou added the comment:
Does this mean that PyAccu should be visited in tp_traverse and not be
accounted in __sizeof__? Or should we tighten the control and ensure
that PyAccu contains only exact Unicode objects?
IMO, the latter.
--
___
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
___
Python-bugs-list mailing list
Serhiy Storchaka added the comment:
For the PyAccu, AFAICT, objects cannot leak out of it (except for
gc.getobjects in debug mode).
Not only in debug mode.
import io, gc
s=io.StringIO()
s.write('12345')
5
s.write('qwerty')
6
for o in gc.get_objects():
... if '123 in repr(o) and
Martin v. Löwis added the comment:
For the PyAccu, AFAICT, objects cannot leak out of it (except for
gc.getobjects in debug mode).
Not only in debug mode.
I see. I meant sys.getobjects, which is in debug mode only, but
I now see that gc.get_objects will get the list (but not the strings)
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file26588/stringio_sizeof-2.7.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
New submission from Serhiy Storchaka:
Here is a patch that implements correct __sizeof__ for C implementation of
io.StringIO.
I haven't tested the patch on narrow build.
--
components: IO, Library (Lib)
files: stringio_sizeof-3.3.patch
keywords: patch
messages: 166807
nosy:
Changes by Serhiy Storchaka storch...@gmail.com:
Added file: http://bugs.python.org/file26587/stringio_sizeof-3.2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15490
___
Antoine Pitrou added the comment:
Here is a patch that implements correct __sizeof__ for C implementation of
io.StringIO.
For some value of correct, since the internal accumulator could hold
alive some unicode strings.
I haven't tested the patch on narrow build.
There's no narrow build
Serhiy Storchaka added the comment:
For some value of correct, since the internal accumulator could hold
alive some unicode strings.
This is not a concern of __sizeof__, because these lists and strings are
managed by GC.
There's no narrow build anymore on 3.3.
I mean 2.7 and 3.2. I have
Antoine Pitrou added the comment:
For some value of correct, since the internal accumulator could hold
alive some unicode strings.
This is not a concern of __sizeof__, because these lists and strings are
managed by GC.
It is, since they are private and not known by the user.
Martin v. Löwis added the comment:
The question really is what memory blocks can leak out of the object, and
those don't really belong to the container. Those shouldn't be accounted for,
since somebody else may get hold of them, and pass them to sys.sizeof.
For the PyAccu, AFAICT, objects
36 matches
Mail list logo
