[Python-3000] UPDATED: PEP 3138- String representation in Python 3000

[Blake Winton]

Nick Coghlan wrote:
> Oleg Broytmann wrote:
>>    str(container) not calling str() on items is at least a strange and
>> unexpected behaviour, if not a bug.
> I have no problem at all with people calling this behaviour surprising 
> and unexpected, but I'm not happy with them calling it a bug without 
> being challenged, since there are very good reasons for it working the 
> way it does.
> 
> str([1, 2, 3]), str(list("123")) and str(["1, 2, 3"]) should all produce 
> distinctive output: calling repr() on container contents achieves this, 
> calling str() does not.

Why?

Seriously, I can write:
 >>> print 1, "1", Decimal("1")
and get as my output:
1 1 1
and somehow no-one complains that it should actually print:
1 "1" Decimal("1")
but for some reason when I put those in a list, they should magically 
change their display?

I think the burden of proof is on you to explain why, when we have a 
perfectly good name for unambiguous output ("repr"), do we need to 
override the name for ambiguous and nicely-formatted output ("str"), to 
achieve the same goal.

> While it could be argued that if you want unambiguous output you should 
> be invoking repr() on the container instead of str(), I'm still seeing 
> many more downsides than upsides to the idea of making str() on the 
> builtin containers display their contents with str() instead of repr().

But which downsides do you see that aren't solved by the use of repr to 
get unambiguous output?

Later,
Blake.