(original) (raw)
Actually changing __str__ or __repr__ is out of the question, best we can do is discourage makingbthem different. But adding a protocol for pprint (with extra parameters to convey options) is a fair idea. I note that Nick sggested to use single-dispatch generic functions for this though. Both have pros and cons. Post design ideas to python-ideas please, not here!
--Guido
On Tuesday, May 21, 2013, Łukasz Langa wrote:
On Tuesday, May 21, 2013, Łukasz Langa wrote:
On 20 maj 2013, at 03:46, Guido van Rossum <guido@python.org> wrote:On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith <greg@krypto.org> wrote:
Now you've got me wondering what Python would be like if repr, \`\` and
\_\_repr\_\_ never existed as language features. Upon first thoughts, I actually
don't see much downside (no, i'm not advocating making that change).
Something to ponder.
I have pondered it many times, although usually in the form "Why do we
need both str and repr?"What if we did the opposite?1\. Make \_\_str\_\_() a protocol for arbitrary string conversion.2\. Move the current \_\_repr\_\_() contracts, both firm and informal to a new, extensible version of pprint.There has been some discussion led by Raymond in 2010 about a general \`pprint rewrite\`\_\_ and I'm willing to pick up the idea with a PEP for inclusion in 3.4.\_\_ http://bugs.python.org/issue7434
--
--Guido van Rossum (python.org/\~guido)