Ian D. Bollinger writes: > This is somewhat tangental, but hopefully an $r formatting operation > won't be necessary in Py3k, assuming repr() and str() can somehow be > combined.
Nick Coghlan responds: > repr() (machine readable) and str() (human readable) do different things, > so why would combining them even be considered? First, the history as I understand it: repr() and str() are both concerned with turning an object into a string that vaguely describes it. (Turning it into a string that completely describes it is called serialization, and neither of these functions performs that reliably.) In the special (but rather important) case of strings (including unicode) there is a basic ambiguity of whether you want to display the string itself (after all, it's already a string) or provide quoting and escaping. This ambiguity was solved by creating two different methods, str() and repr(). A general rule was promulgated: str() should produce human readable strings, and repr() should produce something which could be fed to eval() to recreate the original *if that's easy to do*, and something readable in other cases. In practice, a huge number of classes implement the two identically. The argument in favor of combining the two (the result would be named "str", hence the subject line): There are NOT two different fundamental ideas here, so we don't *really* need two different functions. Perhaps we need some way (unspecified... lots of clever ways could be suggested) to control whether strings are escaped-and-quoted or not, but that's it. Making repr() produce something which can be used with eval() to recreate the original object was always a dream: it fails in an enormous number of real cases and there are better ways to do serialization anyhow. Furthermore, the existing situation creates confusion. It is difficult to explain to newbies, and even experts like Nick wind up eroniously beliving that repr() generates a "machine readable" form. (I'm going out on a limb here, claiming that I'm right and Nick is wrong, but I'm going to stand by the claim anyhow. Anything which is machine readable "sometimes" is, by my definition, NOT machine readable!) The argument AGAINST combining the two is as follows: There would be a huge amount of gratuitous code breakage, for the sake of eliminating a little confusion (which isn't even a major source of bugs). It isn't worth the effort of re-writing code (even though python 3000 may break code, most not-too-clever code from python 2.x ought to work fine with perhaps a few modifications). In my opinion, the argument against wins. I move we list this in PEP 3099. -- Michael Chermside _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
