On Sun, Oct 23, 2011 at 7:44 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
Those examples are objects which are effectively identical in each instance. (In the case of None, there is only one instance). Those are the unusual case; the common case is that objects of a given type are different form each other, and that frequently means their printable representation should be different too.
If the instances have a name (e.g. function objects), I agree the name should be *included in* the string representation. But there's usually other useful information that should also be included.
Until we fix the qualified name problem for nested functions and classes, there isn't really other information of interest to be included (and I'm going back on some I said earlier here). While we *could* include __module__ (especially since class repr's already include it), it's sometimes actively misleading to do so. By only including __name__, we deliberately underqualify *everything*, so "str(cls)" and "str(func)" just refers to the name they were defined with and omits any additional context. The current convention is that classes, functions and modules, don't offer a shorthand "pretty" display format at all. The proposal is to specifically bless "x.__name__" as an official shorthand. Sure, sometimes you won't *want* the shorthand, so you'll need to either explicitly ask for repr(), or otherwise construct your own description from individual attributes. That's true for a lot of other types as well (especially when it comes to numbers). I think the most valid objection raised so far is the fact that some metaclasses *already* override __str__ to display something other than the result of type.__repr__(cls). That does have the potential to cause problems for code dealing with utterly unknown types. However, such code should likely be explicitly invoking repr() rather than str() anyway, so this change is unlikely to break anything that isn't already broken. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia