Repr of collection's subclasses #71728

Activity

1. serhiy-storchaka commented on Jul 17, 2016

   

   serhiy-storchaka

   on Jul 17, 2016

   MemberAuthor

   More actions

   The repr of subclasses of some collection classes contains a name of the subclass:

   >>> class S(set): pass
   ... 
   >>> S([1, 2, 3])
   S({1, 2, 3})
   >>> import collections
   >>> class OD(collections.OrderedDict): pass
   ... 
   >>> OD({1: 2})
   OD([(1, 2)])
   >>> class C(collections.Counter): pass
   ... 
   >>> C('senselessness')
   C({'s': 6, 'e': 4, 'n': 2, 'l': 1})

   But the repr of subclasses of some collection classes contains a name of the base class:

   >>> class BA(bytearray): pass
   ... 
   >>> BA([1, 2, 3])
   bytearray(b'\x01\x02\x03')
   >>> class D(collections.deque): pass
   ... 
   >>> D([1, 2, 3])
   deque([1, 2, 3])
   >>> class DD(collections.defaultdict): pass
   ... 
   >>> DD(int, {1: 2})
   defaultdict(<class 'int'>, {1: 2})

   Shouldn't a name of the subclass always be used?
2. serhiy-storchaka

   added

   extension-modulesC modules in the Modules dirC modules in the Modules dir

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   type-featureA feature request or enhancementA feature request or enhancement

   on Jul 17, 2016
3. zhangyangyu commented on Jul 17, 2016

   

   zhangyangyu

   on Jul 17, 2016

   Member

   More actions

   How about other built-in classes? If repr does matter, maybe str, int, dict should also respect this rule?
4. serhiy-storchaka commented on Jul 17, 2016

   

   serhiy-storchaka

   on Jul 17, 2016

   MemberAuthor

   More actions

   This can break third-party code. For example the code that explicitly makes the repr containing a subclass name:

   class MyStr(str):
       def __repr__(self):
           return 'MyStr(%s)' % str.__repr__(self)

   I think the chance of breaking third-party code for bytearray or deque is smaller, since the repr is not literal.
5. zhangyangyu commented on Jul 17, 2016

   

   zhangyangyu

   on Jul 17, 2016

   Member

   More actions

   Yes. So if we are not going to change other built-in types, maybe we'd better not change bytearray either. My opinion is that don't change built-in classes, even bytearray. If users would like a more reasonable repr, they can provide a custom __repr__ as your example. But make such changes to classes in collections sounds like a good idea to me.
6. rhettinger

   self-assigned this

   on Jul 17, 2016
7. bitdancer commented on Jul 17, 2016

   

   bitdancer

   on Jul 17, 2016

   Member

   More actions

   It certainly seems that collections should be consistent about this. The question of builtin types is a different issue, and I agree that it is probably way more trouble than it is worth to change them, especially since, for example, repr(str) is often used just to get the quote marks in contexts where you *don't* want the subclass name.
8. serhiy-storchaka commented on Jul 17, 2016

   

   serhiy-storchaka

   on Jul 17, 2016

   MemberAuthor

   More actions

   It looks to me that the repr of a collection contains a dynamic name if it is implemented in Python and hardcoded base name if it is implemented in C (OrderedDict originally was implemented in Python). Maybe just because tp_name contains full qualified name, and extracting a bare class name needs few lines of code.

   There is similar issue with the io module classes: bpo-21861.

   Since this problem is already solved for OrderedDict, I think it is easy to use this solution in other classes. Maybe factoring out the following code into helper function.

       const char *classname;

       classname = strrchr(Py_TYPE(self)->tp_name, '.');
       if (classname == NULL)
           classname = Py_TYPE(self)->tp_name;
       else
           classname++;
9. serhiy-storchaka

   added

   3.7 (EOL)end of lifeend of life

   on Sep 17, 2017
10. rhettinger commented on Sep 17, 2017

    

    rhettinger

    on Sep 17, 2017

    Contributor

    More actions

    +1 for changing the cases Serhiy found. Also, I agree with Serhiy that there should not be a change for the built-in types that have a literal notation (it has been this was forever, hasn't caused any real issues, and changing it now will likely break code).
11. serhiy-storchaka commented on Sep 21, 2017

    

    serhiy-storchaka

    on Sep 21, 2017

    MemberAuthor

    More actions

    New changeset b3a7796 by Serhiy Storchaka in branch 'master':
    bpo-27541: Reprs of subclasses of some classes now contain actual type name. (bpo-3631)
    b3a7796
12. serhiy-storchaka commented on Sep 21, 2017

    

    serhiy-storchaka

    on Sep 21, 2017

    MemberAuthor

    More actions

    Thanks Raymond.
13. serhiy-storchaka

    closed this as completedon Sep 21, 2017
14. vstinner commented on Sep 21, 2017

    

    vstinner

    on Sep 21, 2017

    Member

    More actions

    Why using type.__name__ rather than type.__qualname__?
15. serhiy-storchaka commented on Sep 21, 2017

    

    serhiy-storchaka

    on Sep 21, 2017

    MemberAuthor

    More actions

    Because reprs of Python implementations of collection use a bare __name__.

    __qualname__ is used only in combination with __module__. Using a single __qualname__ can be confused: foo.bar looks as a name bar in the module foo. Whether in reprs and error messages either full qualified name is used ("{cls.__module__}.{qualname}") or a bare __name__. If a displayed name contains a dot it is always a full qualified name.
16. vstinner commented on Sep 21, 2017

    

    vstinner

    on Sep 21, 2017

    Member

    More actions

    Because reprs of Python implementations of collection use a bare __name__.

    Ah, maybe this module should be updated to use qualified name with the name in repr()?

    __qualname__ is used only in combination with __module__.

    I was thinking at module.qualname, right.
17. ezio-melotti

    transferred this issue fromon Apr 10, 2022