classification
Title: Use __qualname__ together with __module__
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: serhiy.storchaka Nosy List: barry, haypo, python-dev, rkuska, serhiy.storchaka
Priority: normal Keywords: patch

Created on 2014-07-22 09:02 by serhiy.storchaka, last changed 2015-09-24 14:28 by haypo. This issue is now closed.

Files
File name Uploaded Description Edit
repr_qualname.diff serhiy.storchaka, 2014-07-22 09:02 review
Messages (13)
msg223649 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-07-22 09:02
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.
msg223651 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2014-07-22 09:14
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.
msg223661 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-07-22 11:52
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.
msg223663 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2014-07-22 11:54
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 :-)
msg223664 - (view) Author: Roundup Robot (python-dev) Date: 2014-07-22 12:00
New changeset fe3c98313855 by Serhiy Storchaka in branch 'default':
Issue #22032: __qualname__ instead of __name__ is now always used to format
http://hg.python.org/cpython/rev/fe3c98313855
msg223665 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-07-22 12:05
I agree with you. Thank for your review Victor.

All these issues are precursors to issue22033.
msg245690 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2015-06-23 13:57
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.
msg251489 - (view) Author: Robert Kuska (rkuska) * Date: 2015-09-24 07:03
FYI This also broke nosetests tests which relies on exact output.

https://github.com/nose-devs/nose/issues/928
msg251500 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2015-09-24 07:57
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 ?
msg251501 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2015-09-24 07:59
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 :-)
msg251512 - (view) Author: Robert Kuska (rkuska) * Date: 2015-09-24 11:47
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).
msg251527 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2015-09-24 14:16
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>.
msg251530 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2015-09-24 14:28
Ok, anyway, thanks for your feedback.
History
Date User Action Args
2015-09-24 14:28:23hayposetmessages: + msg251530
2015-09-24 14:16:44barrysetmessages: + msg251527
2015-09-24 11:47:51rkuskasetmessages: + msg251512
2015-09-24 07:59:00hayposetmessages: + msg251501
2015-09-24 07:58:00hayposetmessages: + msg251500
2015-09-24 07:03:47rkuskasetnosy: + rkuska
messages: + msg251489
2015-06-23 13:57:02barrysetnosy: + barry
messages: + msg245690
2014-07-22 12:05:15serhiy.storchakasetstatus: open -> closed
messages: + msg223665

assignee: serhiy.storchaka
resolution: fixed
stage: patch review -> resolved
2014-07-22 12:00:35python-devsetnosy: + python-dev
messages: + msg223664
2014-07-22 11:54:22hayposetmessages: + msg223663
2014-07-22 11:52:07serhiy.storchakasetmessages: + msg223661
versions: - Python 3.4
2014-07-22 09:14:40hayposetnosy: + haypo
messages: + msg223651
2014-07-22 09:02:36serhiy.storchakacreate