Often when class name is reported in stdlib (e.g. in reprs), it used together with module name: '%s.%s' % (self.__class__.__module__, self.__class__.__name__). But this code is wrong when a class is nested. The __qualname__ attribute should be used instead of just __name__ (and it is already used in multiple places).

Proposed patch replaces __name__ to __qualname__ when it used together with module name to format full class name.

The patch looks good to me.

For Python 3.4, may it break the backward compatibility? For example, breaking doctests relying on the exact representation? If there is a risk, it's maybe safer to only modify Python 3.5.

It broke Python tests (test_traceback and test_unittest), and the patch contains fixes for this. Yes, it can break user test if they test nested subclasses of classes touched by this patch. This is not very likely, but on other hand I don't see what can happen wrong when we will not fix it in 3.4.

If an application relies on the exact representation in an unit test, it would be annoying to check the minor Python version to support the old and the new format.

Using the qualified name is better, but it can wait Python 3.5 IMO. They are enough complains that Python breaks backward compatibility, which is true or not :-)

New changeset fe3c98313855 by Serhiy Storchaka in branch 'default':
Issue bpo-22032: __qualname__ instead of __name__ is now always used to format
http://hg.python.org/cpython/rev/fe3c98313855

I agree with you. Thank for your review Victor.

All these issues are precursors to bpo-22033.

FWIW, this broke the zope.testing doctests:

https://bugs.launchpad.net/zope.testing/+bug/1467644

I submitted a patch, which was reasonable given the normalization that zope.testing does for doctest output, but people should be aware that this can break doctests. Unfortunately, short of the normalizing tricks that zope.testing does, there's no way to write such tests that are compatible with both 3.4 and 3.5. OTOH, I agree that raising nested exceptions the way zope.testing does is probably rare.

FYI This also broke nosetests tests which relies on exact output.

nose-devs/nose#928

Barry, Robert: I'm sorry that the change broke tests, but tests should not rely on the exact representation. They can test type(obj).__name__ for example.

Barry: "people should be aware that this can break doctests"

Some years ago, I was a big fan of doctest. But with the release of Python 3, I now think that it's a big mess. It's very hard to write reliable doctests. Most doctests rely on the exact representation of objects and subtle details which break on minor Python releases.

IHMO it's better to write classic unittest tests and use functions like assertEqual(). By the way, the unittest made great progress last years, it shows better error message when a test fails.

Maybe we should document better such changes in the https://docs.python.org/dev/whatsnew/3.5.html#porting-to-python-3-5 section ?

Oh by the way, this issue is closed, what do you expect Barry and Robert? If you consider that it's a bug, please open a new issue and describe what you want :-)

I agree with you Victor that tests shouldn't rely on the exact representation and I also understand why such change was introduced therefore I don't think there is any bug to report, my comment was just pure 'FYI' for anyone who will come across it (as I did).

I'm not expecting a change either, I was also just documenting observed breakages. Given that I've ported a *ton* of code to 3.5 and only seen a handful of failures related to this issue, I agree that it's better just to provide information and let packages fix their code.

I am keeping a running document of such issues here: https://wiki.python.org/moin/PortingToPy3k/34to35

As for the larger question of doctests, we can discuss elsewhere. Probably not appropriate for *this* issue <wink>.

Ok, anyway, thanks for your feedback.