On Mon, May 20, 2013 at 11:46 AM, Guido van Rossum <gu...@python.org> wrote: > On Sun, May 19, 2013 at 4:27 PM, Gregory P. Smith <g...@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?"
<snip> > So it looks like we really need both str(x) and repr(x). But maybe we > only need the __repr__ protocol? str(x) could just special-case its > own type, and use repr(x) (or x.__repr__(), which is the same) in all > other cases. The __repr__() method on the string type would do just > what it does today. But there would not be a __str__() protocol at > all. In my own code, I tend to map "__repr__" to either object identity (the classic "<unevalable-info>" format) or object reconstruction (the not-quite-as-classic-but-still-popular "ClassName(constructor_args)" format). I then tend to use "__str__" to emit something that matches any equivalence classes defined through "__eq__". This way of thinking about it does correlate with the "for developers" and "for end user" distinction, but without needing to think about it in those terms. However, even that approach has its limitations, and I offer the existence of both the pprint module and the "__format__" protocol as evidence, along with the multitude of context specific conversion and escaping functions. In many respects, conversion of arbitrary objects to context-appropriate strings is a signature use case for single dispatch generic functions. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
