On Sat, Oct 22, 2011 at 10:23 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Nick Coghlan wrote: [...]
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.
I believe you are saying that backwards.
The way to get the shorthand display format (i.e. the object's name) is already to use x.__name__. There's no need for a proposal to bless x.__name__ as the way to do it since that's already what people do.
This proposal is to bless str(x) (and equivalent forms) as a shorthand for x.__name__, and *unbless* x.__name__ as the official way to do it. I expect that's what you mean.
That is putting words in my mouth. There's no intent to unbless x.__name__, period. Also, there's no intent to bless str(x) as x.__name__ if you want the name. The only intent is to make what gets printed if you print a function, class or module to be less verbose.
For the avoidance of doubt, this only applies to x a module, function or class (including built-in types) but not necessarily any other kind of object.
[...]
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.
If this proposal goes ahead, will str(x) => x.__name__ cease to be an implementation detail and become part of the public API that *must* be supported by all Python implementations?
(That is not a rhetorical question.)
str() is never an implementation detail. The expectation is that str() is roughly compatible on different Python implementations. If it was an implementation detail, I wouldn't have sustained this discussion for so long, I'd just committed the change. At the same time I see no reason for other implementations not to follow CPython for this particular proposal, and if they disagree they should argue here, not refuse to implement the change.
If not, then other Pythons can return something else and anyone who cares about writing portable, correct code can't use str(x) as shorthand and will still need to use x.__name__. str(x) will then be an attractive nuisance encouraging people to write non-portable code.
I assume that people will continue to understand that str()'s contract is weak -- it produces a pretty string. The only place where its contract is stronger is for some specific types, like str itself (str() of a string is that string itself, period) and for integers and floats (a decimal representation). We're not changing the strength of the contract here. We're just making it prettier.
But if so, that seems rather heavy-handed to me. str() of every other kind of object is an implementation detail[1]. Presumably if there were an Italian Python where str(None) returned "Nessuno", or a Persian Python where str(2) returned "۲", that would be allowed. I don't see that classes are special enough to justify making the precise output of str(cls) part of the public API of classes.
It seems to me you are reading too much into the proposal. Please back down. The sky is not falling.
[1] Although it has to be acknowledged that many objects have an obvious string output that is very unlikely to change.
-- --Guido van Rossum (python.org/~guido)