Repository navigation
Use __qualname__ together with __module__ #66231
Description
| BPO | 22032 |
|---|---|
| Nosy | @warsaw, @vstinner, @serhiy-storchaka, @rkuska |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/serhiy-storchaka'
closed_at = <Date 2014-07-22.12:05:15.134>
created_at = <Date 2014-07-22.09:02:36.309>
labels = ['type-bug', 'library']
title = 'Use __qualname__ together with __module__'
updated_at = <Date 2015-09-24.14:28:23.251>
user = 'https://github.com/serhiy-storchaka'bugs.python.org fields:
activity = <Date 2015-09-24.14:28:23.251>
actor = 'vstinner'
assignee = 'serhiy.storchaka'
closed = True
closed_date = <Date 2014-07-22.12:05:15.134>
closer = 'serhiy.storchaka'
components = ['Library (Lib)']
creation = <Date 2014-07-22.09:02:36.309>
creator = 'serhiy.storchaka'
dependencies = []
files = ['36026']
hgrepos = []
issue_num = 22032
keywords = ['patch']
message_count = 13.0
messages = ['223649', '223651', '223661', '223663', '223664', '223665', '245690', '251489', '251500', '251501', '251512', '251527', '251530']
nosy_count = 5.0
nosy_names = ['barry', 'vstinner', 'python-dev', 'serhiy.storchaka', 'rkuska']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue22032'
versions = ['Python 3.5']
Activity
serhiy-storchaka commentedon Jul 22, 2014
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.
vstinner commentedon Jul 22, 2014
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.
serhiy-storchaka commentedon Jul 22, 2014
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.
vstinner commentedon Jul 22, 2014
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 :-)
python-dev commentedon Jul 22, 2014
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
serhiy-storchaka commentedon Jul 22, 2014
I agree with you. Thank for your review Victor.
All these issues are precursors to bpo-22033.
warsaw commentedon Jun 23, 2015
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.
rkuska commentedon Sep 24, 2015
FYI This also broke nosetests tests which relies on exact output.
nose-devs/nose#928
vstinner commentedon Sep 24, 2015
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 ?
vstinner commentedon Sep 24, 2015
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 :-)
rkuska commentedon Sep 24, 2015
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).
warsaw commentedon Sep 24, 2015
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>.
vstinner commentedon Sep 24, 2015
Ok, anyway, thanks for your feedback.