Antoine Pitrou added the comment:
Why would you want to speed up repr()? I'm -1 unless there's an use case.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19653
___
STINNER Victor added the comment:
After writing the patch, I realized that it adds a lot of new functions and add
more code. Then I asked myself if repr() is really an important function or not
:-)
3 other developers ask the same question, so it's probably better to reject
this huge patch
New submission from STINNER Victor:
The _PyUnicodeWriter API avoids creation of temporary Unicode strings and has
very good performances to build Unicode strings with the PEP 393 (compact
unicode string).
Attached patch adds a _PyObject_ReprWriter() function to avoid creation of
tempory
Eric Snow added the comment:
As far as I'm aware, the performance of __repr__() for any object is not much
of a concern. Repr is mostly for debugging and interactive use, so it's
already fast/efficient enough for the target consumers: us. :) Making
__repr__() easier to write or maintain is
Serhiy Storchaka added the comment:
I supported patches for repr(list), repr(tuple) and repr(dict) because they
made the code shorter and cleaner. But this patch is more questionable.
--
___
Python tracker rep...@bugs.python.org
