On Fri, Oct 28, 2011 at 9:15 AM, Éric Araujo <merwok@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)