[Peter Funk]
> ...
> So if default behaviour of the interactive interpreter would be changed
> not to use 'repr()' for objects typed at the prompt (I believe Tim
> Peters suggested that), this wouldn't help to make lists, tuples and
> dictionaries containing floats more readable.
Or lists, tuples and dicts of anything else either: that's what I'm getting
at when I keep saying containers should "pass str() down" to containees.
That it doesn't has frustrated me for years; newbies aren't bothered by it
because before 1.6 str == repr for almost all builtin types, and newbies (by
definition <wink>) don't have any classes of their own overriding __str__ or
__repr__. But I do, and their repr is rarely what I want to see in the
shell.
This is a different issue than (but related to) what the interactive prompt
should use by default to format expression results. They have one key
conundrum in common, though: if str() is simply passed down with no other
change, then e.g.
print str({"a:": "b, c", "a, b": "c"})
and (same thing in disguise)
print {"a:": "b, c", "a, b": "c"}
would display
{a:: b, c, a, b: c}
and that's darned unreadable. As far as I can tell, the only reason
str(container) invokes repr on the containees today is simply to get some
string quotes in output like this. That's fine so far as it goes, but leads
to miserably bloated displays for containees of many types *other* than the
builtin ones -- and even for string containees leads to embedded octal
escape sequences all over the place.
> I don't know how to fix this, though. :-(
Sure you do! And we look forward to your patch <wink>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4