You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Show the address in the repr for class objects #69734
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/kushaldas'closed_at=<Date2016-07-14.04:13:42.855>created_at=<Date2015-11-03.18:40:11.560>labels= ['type-feature', 'release-blocker']
title='Show the address in the repr for class objects'updated_at=<Date2016-07-14.04:13:42.849>user='https://github.com/rhettinger'
In old-style classes, the memory address of the class object is shown for both the class and for the instance. In new-style classes, only the instance shows the address. I and other Python instructors have found the memory address display to be useful and I think it should be added back:
Old-style
=========
>>> class A:
pass
>>> a = A()
>>> A
<class __main__.A at 0x10061e328>
>>> a
<__main__.A instance at 0x105292cb0>
New-style
=========
>>> class A(object):
pass
>>> a = A()
>>> A
<class '__main__.A'>
>>> a
<__main__.A object at 0x105332cd0>
I just executed the code with python 3.5 and I don't have this result:
Python 3.5.0 (default, Sep 23 2015, 04:41:38)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> classA: pass
...
>>> A
<class '__main__.A'>
>>> classA(object): pass
...
>>> A
<class '__main__.A'>
>>>
I don't quite get why the memory address is helpful
For the same reason that we've found the address to helpful in other reprs, it helps people understand that classes are objects just like anything else and to know which objects are distinct.
My instructors have found that this matters when teaching Python and more than one of them immediately noticed the loss of information when switching from teaching Python 2 to Python 3.
Uploading the new patch with a new test case for the same.
Vgr255 commented on Jun 3, 2016
Vgr255mannequin
Mannequin
More actions
I'd probably change all instances of ".*" in the regex matches to be "0x.+" instead. For the docstrings that have "..." in them, I would probably make those " at ..." as well (although you get decide if it hinders readability too much).
Kushal. If you don't mind, I would like Nofar to be able to do this patch. She's been working on it since before the sprints and was slowed down by a schoolwork crunch.
Nofar is about to upload her patch as well (she's been working on this for a while). Perhaps the two can be compared and reconciled so that both can be credited on the commit.
Hey Raymond, I am uploading the patch which I almost committed along with whats new update :)
I am also reassigning the ticket to you so that you can decide the next steps.
I understand the reasoning here, but I want to say booh to this change in 3.6.0a2 because it breaks my tests. It used to be that type(x) returned a predictable string, and that was an easy way to verify the result types of things.
Perhaps a __str__ implementation could be added that avoids the memory address?
There is also bpo-13224 proposing to change __str__() to just return the __name__ or __qualname__ if I remember correctly.
timgraham commented on Jun 22, 2016
timgrahammannequin
Mannequin
More actions
I'll echo what Peter said and say that this breaks 5 tests in Django's test suite which are checking error messages. If it stays, perhaps it could be added to the release notes instead of just NEWS.
The NEWS file got a typo. Thanks for noticing that.
This change did require a lot of updates to the tests.
If rest of the people agrees to revert this change, then we should go ahead and do it. Just wondering if Raymond has anything to add.
Would there be a way to confine this to just heap types? The user defined classes are where there is the most benefit. For the built-in types, it just seems to add noise.
+1 on rolling this back. It sounds like it hurt more than it would have helped.
To satisfy my curiosity, can you post one of the tests that broke. It would be nice to see what kind of tests are depend the repr of the class. AFAICT, there was never an issue with this for old-style classes in Python2.7, so something new must be occurring in the wild.
The reason it never was an issue for old-style classes is that they
behaved like this from the start, so nobody wrote tests that depended
on the predictability of repr(). But new-style classes have had this
nice clean repr() since they were introduced (in 2.3?) so it's
unsurprising that this is now depended upon.
It may be irreprehensible code but it works for Python 3.2-3.5 (and
for new-style classes in Python 2, except mypy requires Python 3), and
broke in 3.6.
Activity
rhettinger commentedon Nov 3, 2015
In old-style classes, the memory address of the class object is shown for both the class and for the instance. In new-style classes, only the instance shows the address. I and other Python instructors have found the memory address display to be useful and I think it should be added back:
Old-style
=========
New-style
=========
matrixise commentedon Nov 3, 2015
Hi Raymond,
I just executed the code with python 3.5 and I don't have this result:
terryjreedy commentedon Nov 6, 2015
In 3.x, old style classes are gone, so you get a new style class with or without '(object)'.
pppery commentedon May 19, 2016
I don't quite get why the memory address is helpful, but you could work around this using a custom metaclass:
IdInReprand all its subclasses will then have the memory address in their representation:<class 'module.name' at address>
rhettinger commentedon May 22, 2016
For the same reason that we've found the address to helpful in other reprs, it helps people understand that classes are objects just like anything else and to know which objects are distinct.
My instructors have found that this matters when teaching Python and more than one of them immediately noticed the loss of information when switching from teaching Python 2 to Python 3.
kushaldas commentedon Jun 2, 2016
Attaching the patch for the same. Had to update the test cases for the following tests to have this behavior as expected.
test_functools
test_cmd_line_script
test_ctypes
test_defaultdict
test_descr
test_descrtut
test_doctest
test_generators
test_genexps
test_metaclass
test_pprint
test_reprlib
test_statistics
test_trace
test_wsgiref
kushaldas commentedon Jun 3, 2016
Uploading the new patch with a new test case for the same.
Vgr255 commentedon Jun 3, 2016
I'd probably change all instances of ".*" in the regex matches to be "0x.+" instead. For the docstrings that have "..." in them, I would probably make those " at ..." as well (although you get decide if it hinders readability too much).
Other than that patch LGTM.
brettcannon commentedon Jun 3, 2016
Patch LGTM. Just needs doc and What's New updates.
rhettinger commentedon Jun 3, 2016
Kushal. If you don't mind, I would like Nofar to be able to do this patch. She's been working on it since before the sprints and was slowed down by a schoolwork crunch.
rhettinger commentedon Jun 3, 2016
Nofar is about to upload her patch as well (she's been working on this for a while). Perhaps the two can be compared and reconciled so that both can be credited on the commit.
kushaldas commentedon Jun 3, 2016
Hey Raymond, I am uploading the patch which I almost committed along with whats new update :)
I am also reassigning the ticket to you so that you can decide the next steps.
6 remaining items
Shredder13 commentedon Jun 5, 2016
Kushal, you've beat me to it. Great work!
Carreau commentedon Jun 7, 2016
Hi guys, the title of the issues is "show address in the **repR**", but the NEWS file says[1] in the **repL*, which are 2 different things ! :-)
And this patch change the repR so it also affect scripts and unittests.
[1] since https://hg.python.org/cpython/rev/af29d89083b3
petere commentedon Jun 18, 2016
I understand the reasoning here, but I want to say booh to this change in 3.6.0a2 because it breaks my tests. It used to be that type(x) returned a predictable string, and that was an easy way to verify the result types of things.
Perhaps a __str__ implementation could be added that avoids the memory address?
vadmium commentedon Jun 18, 2016
There is also bpo-13224 proposing to change __str__() to just return the __name__ or __qualname__ if I remember correctly.
timgraham commentedon Jun 22, 2016
I'll echo what Peter said and say that this breaks 5 tests in Django's test suite which are checking error messages. If it stays, perhaps it could be added to the release notes instead of just NEWS.
gvanrossum commentedon Jul 12, 2016
I'm also echoing this... It breaks too many tests. I filed bpo-27498.
kushaldas commentedon Jul 13, 2016
The NEWS file got a typo. Thanks for noticing that.
This change did require a lot of updates to the tests.
If rest of the people agrees to revert this change, then we should go ahead and do it. Just wondering if Raymond has anything to add.
rhettinger commentedon Jul 13, 2016
Would there be a way to confine this to just heap types? The user defined classes are where there is the most benefit. For the built-in types, it just seems to add noise.
gvanrossum commentedon Jul 13, 2016
Doing it only for user-defined types would still break my tests.
rhettinger commentedon Jul 13, 2016
+1 on rolling this back. It sounds like it hurt more than it would have helped.
To satisfy my curiosity, can you post one of the tests that broke. It would be nice to see what kind of tests are depend the repr of the class. AFAICT, there was never an issue with this for old-style classes in Python2.7, so something new must be occurring in the wild.
gvanrossum commentedon Jul 13, 2016
Thanks, let's roll it back.
The reason it never was an issue for old-style classes is that they
behaved like this from the start, so nobody wrote tests that depended
on the predictability of repr(). But new-style classes have had this
nice clean repr() since they were introduced (in 2.3?) so it's
unsurprising that this is now depended upon.
Here's a link to some test code for mypy that broke:
https://github.com/python/mypy/blob/master/mypy/util.py#L22-L23
It may be irreprehensible code but it works for Python 3.2-3.5 (and
for new-style classes in Python 2, except mypy requires Python 3), and
broke in 3.6.
python-dev commentedon Jul 14, 2016
New changeset 4f11e6b72e8f by Benjamin Peterson in branch 'default':
Backed out changeset af29d89083b3 (closes bpo-25548) (closes bpo-27498)
https://hg.python.org/cpython/rev/4f11e6b72e8f