[Python-ideas] Changing str(someclass) to return only the class name

Guido van Rossum guido at python.org
Fri Oct 28 19:51:47 CEST 2011


On Fri, Oct 28, 2011 at 9:15 AM, Éric Araujo <merwok at netwok.org> wrote:
> Le 22/10/2011 22:18, Steven D'Aprano a écrit :
>> I'm just going to repeat what I've said before: explicit is better than
>> implicit. If you want the name of an object (be it a class, a module, a
>> function, or something else), you should explicitly ask for the name,
>> and not rely on its str().
>>
>> [...]
>>
>> But for the sake of the argument, I'll grant you that we're free to
>> change str(cls) to return the class name, as requested by the OP, or the
>> fully qualified module.class dotted name as suggested by you. So let's
>> suppose that, after a long and bitter debate over which colour to paint
>> this bikeshed, you win the debate.
>
> Hm.  Sometimes we want the class name, sometimes module.class, so even
> with the change we won’t always be able to use str(cls).

It is a well-known fact of humanity that you can't please anyone.
There's not that much data on how often the full name is better; my
hunch however is that most of the time the class name is sufficiently
unique within the universe of classes that could be printed, and
showing the module name just feels pedantic. Apps that know just the
name is sub-optimal should stick to rendering using cls.__module__ and
cls.__name__.

>> But this doesn't help you at all, because you can't rely on it. It seems
>> to me that the exact format of str(cls) is an implementation detail. You
>> can't rely on other Pythons to do the same thing, nor can you expect a
>> guarantee that str(cls) won't change again in the future. So if you care
>> about the exact string that gets generated, you still have to explicitly
>> use cls.__name__ just as you do now.
>
> This is a very good point.
>
> The output of repr and str is not (TTBOMK) exactly defined or
> guaranteed; nonetheless, I expect that many people (including me) rely
> on some conversions (like the fact that repr('somestr') includes
> quotes).  So we can change str(cls) and say that *now* it has defined
> output, or leave it alone to avoid breaking code that does depend on the
> output, which can be seen as a wrong thing or a pragmatic thing (“I need
> it and it works”).

In my view, str() and repr() are both for human consumption (though in
somewhat different contexts). If tweaking them helps humans understand
the output better then let's tweak them. If you as a developer feel
particularly anal about how you want your object printed, you should
avoid repr() or str() and write your own formatting function.

If as a programmer you feel the urge to go parse the output of repr()
or str(), you should always *know* that a future version of Python can
break your code, and you should file a feature request to have an API
added to the class so you won't have to parse the repr() or str().

-- 
--Guido van Rossum (python.org/~guido)



More information about the Python-ideas mailing list