This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: io class name are hardcoded in reprs
Type: behavior Stage: patch review
Components: Extension Modules, IO Versions: Python 3.3, Python 3.4, Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Claudiu.Popa, Philip Dye, Windson Yang, asaka, benjamin.peterson, hynek, josh.r, piotr.dobrogost, pitrou, rhettinger, serhiy.storchaka, stutzbach
Priority: normal Keywords: easy, patch

Created on 2014-06-24 17:36 by serhiy.storchaka, last changed 2022-04-11 14:58 by admin.

Pull Requests
URL Status Linked Edit
PR 14774 open python-dev, 2019-07-14 10:47
PR 30824 open asaka, 2022-01-23 10:01
Messages (6)
msg221476 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-06-24 17:36
>>> import io
>>> class F(io.FileIO): pass
>>> f = F('/dev/null', 'r')
>>> f
<_io.FileIO name='/dev/null' mode='rb'>
>>> class B(io.BufferedReader): pass
>>> b = B(f)
>>> b
<B name='/dev/null'>
>>> class T(io.TextIOBufferedReader): pass
io.TextIOBase(     io.TextIOWrapper(  
>>> class T(io.TextIOWrapper): pass
>>> t = T(b)
>>> t
<_io.TextIOWrapper name='/dev/null' encoding='UTF-8'>

Expected results are "<__main__.F name='/dev/null' mode='rb'>", "<__main__.B name='/dev/null'>" and "<__main__.T name='/dev/null' encoding='UTF-8'>". Usually reprs of subclass instances substitute actual module and class names.
msg221990 - (view) Author: PCManticore (Claudiu.Popa) * (Python triager) Date: 2014-06-30 23:07
The same should be done for _pyio?
msg221993 - (view) Author: Josh Rosenberg (josh.r) * (Python triager) Date: 2014-06-30 23:31
Is it common for C implementations to introspect to figure out their "real" name? I do this manually for reprs of my user defined classes, but I haven't noticed many built-ins that consider extensibility for the repr. Maybe I'm just not using the classes that do it or I'm overriding the repr without checking?

I just tested, and it looks like frozenset has a subclass friendly repr, while bytearray does not as of 3.4.0. Seems like it might make sense to first determine if introspection should be the default; it would mean a little code bloat every time it's done.
msg222011 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2014-07-01 05:34
> Usually reprs of subclass instances substitute actual module
> and class names.

This is a sensible idea that makes life easier for people writing subclasses.

+1 for your suggestion.
msg222939 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2014-07-13 15:24
I now see that this issue is not so easy from C side.

And more, it is very uncommon for either Python or C implementations (especial C implementations) to introspect to figure out their "real" name. Existing cases are rather exceptions. And in many case this is only a side effect of sharing an implementation between several classes (set and frozenset, three buffered file classes in io, etc). In many cases repr's flexibility is limited: hardcoded or omitted module name, used class's __name__ instead of __qualname__, etc.

This should be discussed on Python-Dev maillist.
msg342684 - (view) Author: Windson Yang (Windson Yang) * Date: 2019-05-17 02:29
IIUC, in the c code we just hardcode the name "_io.FileIO" for "PyFileIO_Type" in If we want to get a dynamic name, we should replace the hardcode name with the module name (like "__main__"). I found this also happens on other modules like collections.
Date User Action Args
2022-04-11 14:58:05adminsetgithub: 66060
2022-01-23 10:01:52asakasetnosy: + asaka
pull_requests: + pull_request29011
2019-08-08 23:44:29Philip Dyesetnosy: + Philip Dye
2019-07-14 10:47:32python-devsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request14567
2019-05-17 02:29:41Windson Yangsetnosy: + Windson Yang
messages: + msg342684
2015-03-24 06:45:56piotr.dobrogostsetnosy: + piotr.dobrogost
2014-07-13 15:24:09serhiy.storchakasetmessages: + msg222939
2014-07-01 05:34:31rhettingersetnosy: + rhettinger
messages: + msg222011
2014-06-30 23:31:01josh.rsetnosy: + josh.r
messages: + msg221993
2014-06-30 23:07:49Claudiu.Popasetnosy: + Claudiu.Popa
messages: + msg221990
2014-06-24 17:36:58serhiy.storchakacreate