Hi,
Le 28/10/2011 19:51, Guido van Rossum a écrit :
On Fri, Oct 28, 2011 at 9:15 AM, Éric Araujo merwok@netwok.org wrote:
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__.
Fair enough.
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().
Okay! I will update the patch to change str(func) and str(module). As it’s a debugging aid meant for human, I won’t update the doc or stdlib to recommend using str(x) instead of x.__name__ and everyone should be happy (or complain before the final release).
Cheers