Roundup Robot devn...@psf.upfronthosting.co.za added the comment:
New changeset f9f782f2369e by Antoine Pitrou in branch '3.2':
Issue #12911: Fix memory consumption when calculating the repr() of huge tuples
or lists.
http://hg.python.org/cpython/rev/f9f782f2369e
New changeset 656c13024ede by
Antoine Pitrou pit...@free.fr added the comment:
I added a comment insisting that the API is private and can be changed at any
moment.
StringIO can actually re-use that API, rather than the reverse. No need to
instantiate a full-blown file object when all you want to do is to join a bunch
of
Martin v. Löwis mar...@v.loewis.de added the comment:
It's not a container type, just a small C struct that
gets allocated on the stack. Think of it as a library, like stringlib.
That's what I call a container type: a structure with a library :-)
That's another possibility. But we'd have
Antoine Pitrou pit...@free.fr added the comment:
That's another possibility. But we'd have to expose a
C API anyway, and this one is as good as any other.
No, it's not: it's additional clutter. If new API needs to be added,
adding it for existing structures is better. Notice that you
Antoine Pitrou pit...@free.fr added the comment:
New patch implementing Martin's suggested optimization (only instantiate the
large list when necessary).
--
Added file: http://bugs.python.org/file23299/accu3.patch
___
Python tracker
Changes by John O'Connor tehj...@gmail.com:
--
nosy: +jcon
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12911
___
___
Python-bugs-list mailing
Martin v. Löwis mar...@v.loewis.de added the comment:
I'm -1 on this approach; I don't think yet another container type is the right
solution, given that we have already plenty of them.
If you want to avoid creating large lists, then the StringIO type should
already provide that. So I wonder
Antoine Pitrou pit...@free.fr added the comment:
I'm -1 on this approach; I don't think yet another container type is
the right solution, given that we have already plenty of them.
It's not a container type, just a small C struct that gets allocated on
the stack. Think of it as a library,
New submission from Antoine Pitrou pit...@free.fr:
In 47176e8d7060, I fixed json to not blow memory when serializing a large
container of small objects.
It turns out that the repr() of tuple objects (and, very likely, list objects
and possibly other containers) has the same problem. For
Antoine Pitrou pit...@free.fr added the comment:
Here is a patch against 3.2.
In the default branch it will also help factor out some code from the _json
module.
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
Changes by Antoine Pitrou pit...@free.fr:
--
keywords: +patch
Added file: http://bugs.python.org/file23109/accu.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12911
___
Antoine Pitrou pit...@free.fr added the comment:
For the record, the patch fixes the test_bigmem crashes when testing repr() on
tuples and lists:
http://www.python.org/dev/buildbot/all/builders/AMD64%20debian%20parallel%20custom/builds/10/steps/test/logs/stdio
--
Antoine Pitrou pit...@free.fr added the comment:
Updated patch (mostly cosmetic stuff) after Benjamin's comments.
--
Added file: http://bugs.python.org/file23111/accu2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12911
13 matches
Mail list logo
