Suggestion by Guido on #868845:

> I sometimes wish that the str() of a class would return the class name
> rather than its repr(); that way "print(str)" would print "str"
> instead of <class 'str'>.  (Use case: printing an exception and its
> message: I wish I could print("%s: %s" % (err.__class__, err)) instead
> of having to use err.__class__.__name__.)

I wrote a simple patch for that.  I just copied the definition of type_repr to a new type_str function, edited the format strings and updated the member mapping (I checked in another file than casting to reprfunc is okay for a str func).  It compiles and runs just fine, but I’m still learning C, so there may be things I’ve missed: I don’t know if I have to declare the new function or something like that.  The test suite passes with very few edits.


Guido added this:
> One could even claim that the repr() of a class could be the same
I for one think of repr first as “string form for debugging”, so I like the angle brackets.  My patch leaves __repr__ alone.


If this get approved, I’ll update my patch with doc changes.  If there is no feedback I’ll go to python-ideas.

It looks like your change breaks backward compatibility (e.g. tests written using doctests). I don't know if it's a problem or not.

I would argue that the previous behavior of str(class) was undefined, or an implementation detail; as a new feature, my patch can break some code that relied on the previous behavior, but we may judge think it’s worth the cost.

BTW, doctest is inherently fragile and broken by many changes, so I’m not too concerned about it.

Here’s the python-ideas thread: #12459">http://mail.python.org/pipermail/python-ideas/2011-October/thread.html#12459

What's holding this up?

[Guido]
> What's holding this up?

- I haven’t updated the patch for function and module objects yet
- I need to catch up with the python-ideas discussion
- There is at least one strong argument against the idea (I’ll point it out on the ML)

I’ve updated my patch to handle modules and functions too, but there is a decision to make.  The functions of built-in modules are implemented by methodobject.c, not functionobject.c (that’s for Python functions), so if we want str(sys.exc_info) to be equal to 'exc_info', then we’ll have str(dict.update) == 'update'.  Is this okay?

The patch needs a review.

- I tried using PyUnicode_FromString(name) instead of PyUnicode_FromFormat("%U", name), just like in Python I would use str(x) instead of '%s' % x, but this caused segfaults.  Is there a simpler function to use?

- I’ve used copy-paste-tweak and checked the results; I’m still learning C and know very little about Python’s types and refcounting internals, so review mercilessly!  I forgot to run the tests in findleaks mode, so I’m doing it right now.

On Wed, Nov 2, 2011 at 9:31 AM, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> I’ve updated my patch to handle modules and functions too, but there is a decision to make.  The functions of built-in modules are implemented by methodobject.c, not functionobject.c (that’s for Python functions), so if we want str(sys.exc_info) to be equal to 'exc_info', then we’ll have str(dict.update) == 'update'.  Is this okay?

Hm, that doesn't seem right. Currently, str(sys.exc_info) says
<built-in function exc_info> but str(dict.update) is <built-in
function exc_info>. So the latter definitely knows that it is an
unbound method! And {}.update is <built-in method update of dict
object at 0x10040c050> so that knows it is a bound method.

I'd be okay if str(sys.exc_info) and str({}.update) were unchanged
from today and if str(dict.update) returned 'dict.update', but if
that's too complicated I'd also be okay with all three being
unchanged, thus limiting this to Python functions (and classes and
modules).

Please also see the proposed PEP 3155 - http://mail.python.org/pipermail/python-ideas/2011-October/012609.html

> Please also see the proposed PEP 3155
I’ve seen it and like it.  I assume you’re telling that we should consider str(cls/mod/func) to return the qname instead of the name?  I think it could be good.  My patch can wait for your PEP, or go in first and be updated later if your PEP is accepted.

I misreported: dict.update is actually okay, but collections.Counter.update (a Python method) is a not an unbound method but a function (py3k-style).

PEP 3155 is accepted and makes str(cls) and str(function) as well as repr(cls) and repr(function) return the qualified name, which obsoletes part of this request.  I haven’t checked if it has the same problem with Python methods.  str(module) is not changed by the PEP.

Are you sure? The way I read the PEP, it just said that str(cls) and
str(func) should *use* qualname. That could mean returning '<function
f.g.h at 0x1234>' or '<class '__main__.C.D>'.

On Tue, Nov 22, 2011 at 7:27 AM, Éric Araujo <report@bugs.python.org> wrote:
>
> Éric Araujo <merwok@netwok.org> added the comment:
>
> PEP 3155 is accepted and makes str(cls) and str(function) as well as repr(cls) and repr(function) return the qualified name, which obsoletes part of this request.  I haven’t checked if it has the same problem with Python methods.  str(module) is not changed by the PEP.
>
> ----------
> title: Change str(class) to return only the class name -> Change str(x) to return only __qualname__ for some types
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue13224>
> _______________________________________
>

You are right, I misinterpreted “use”.  I cloned the the PEP 3155 repo and ran my test script (I’ll attach it for reference) and reprs/strs are indeed "<class '__main__.A.B'>" and "<function makestrip.<locals>.strip at ...>", so this request is not obsoleted.

I’ve updated my patch to use qualnames for str(cls) and str(func).  As I reported before, if I want str(sys.exc_info) to be 'exc_info', then Python unbound methods (i.e. functions) are affected:

    <method 'update' of 'dict' objects>
    <built-in method update of dict object at ...>
    <method 'tolist' of 'array.array' objects>
    <built-in method tolist of array.array object at ...>
 →  Counter.update
    <bound method Counter.update of Counter()>
 →  Top.Nested.method  # this checks qualnames are used
    <bound method Nested.method of <__main__.Top.Nested object at ...>

It seems to me that this is not a problem: Python 3 unbound methods *are* functions.  If you decide that having str(method) unchanged for all kinds of methods is more important than giving all kinds of functions a short str, I can do it.

Ping: I’d like opinions on the request in my last message;

Not 100% sure what you're asking. Is your specific question whether it is okay that str(Counter.update) returns 'Counter.update'? Yes, it is.  Same for Top.Nested.method.

> Is your specific question whether it is okay that str(Counter.update) returns 'Counter.update'?
Yes, sorry if I was unclear.

> Yes, it is.  Same for Top.Nested.method.
Good!  I’ll commit soon.  I’ll make a note in Misc/NEWS, but I don’t think this should go to whatsnew or other doc, as it’s an implementation detail anyway (as discussed on the python-ideas thread).