-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
bpo-21861: Improve _io.FileIO.__repr__ #14774
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-21861: Improve _io.FileIO.__repr__ #14774
Conversation
Hello, and thanks for your contribution! I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA). Unfortunately we couldn't find an account corresponding to your GitHub username on bugs.python.org (b.p.o) to verify you have signed the CLA (this might be simply due to a missing "GitHub Name" entry in your b.p.o account settings). This is necessary for legal reasons before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue. You can check yourself to see if the CLA has been received. Thanks again for your contribution, we look forward to reviewing it! |
dc62f03
to
0a02fcb
Compare
What about other |
8109726
to
47ed9a3
Compare
@serhiy-storchaka Thanks for your comment. I added remaining classes from the |
@@ -1074,22 +1074,26 @@ fileio_repr(fileio *self) | |||
PyObject *nameobj, *res; | |||
|
|||
if (self->fd < 0) | |||
return PyUnicode_FromFormat("<_io.FileIO [closed]>"); | |||
return PyUnicode_FromFormat( | |||
"<%s [closed]>", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be good to have a test for different cases? Something like below in test_fileio.py to ensure C and Python implementations behave the same.
def test_custom_repr(self):
class CustomFileIO(self.FileIO):
pass
custom_file_io = CustomFileIO(TESTFN, 'w')
custom_file_io.close()
self.assertIn("CustomFileIO", repr(custom_file_io))
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR definitely needs tests such as the one proposed here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@taleinat @tirkarthi thanks for comments. I added some tests as suggested.
@beezz, thanks for this PR! Please link your user on bugs.python.org to your GitHub user so that our CLA bot can recognize that you've signed our CLA. |
@beezz, please address the review comments. Thank you! |
47ed9a3
to
bd9440e
Compare
bd9440e
to
3b80300
Compare
Instead of hardcoding the class name in the __repr__ string, resolve the actuall one which makes the __repr__ more subclass friendly.
3b80300
to
996fb04
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good! I think this is almost ready to go.
I have just one significant request regarding the tests (see inline comment).
Also a couple of minor style suggestions and some nitpicking about the NEWS entry, but those aren't critical.
class SubTextIOWrapper(self.TextIOWrapper): | ||
pass | ||
|
||
clsname = 'SubTextIOWrapper' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be simpler and clearer to just hard-code the class name in the strings below.
|
||
custom_file_io = CustomFileIO(TESTFN, 'w') | ||
|
||
self.assertIn( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This check is overly specific: it is testing the implementation's details (the specific formatting, including the order of the values) rather than the intent (that certain values are included).
I suggest something like:
r = repr(custom_file_io)
self.assertIn(clsname, r)
self.assertIn(custom_file_io.name, r)
self.assertIn(custom_file_io.mode, r)
self.assertIn("closefd=True", r)
This is also true for the similar assertion below, and for those in the TextIOWrapper
test as well.
@@ -0,0 +1,2 @@ | |||
Remove the hardcoded classes names from ``_io`` module classes' ``__repr__`` in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that simply mentioning FileIO
and TextIOWrapper
would be clearer than "_io module classes'.
Also I think phrasing this positively would be better, but this is a matter of style:
Use the object's actual class name in :meth:`_io.FileIO.__repr__` and
:meth:`_io.TextIOWrapper.__repr__`, to make these methods subclass friendly.
(For more info about the inline markup used above, see the devguide.)
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Also, @beezz, please avoid rebasing and force-pushing branches which already have an open PR. It is much better, for various reasons, to simply merge the base branch into the PR branch and push the merged branch (this doesn't require force pushing, which is a good sign!). We always squash PR branches before merging them, so the end result is the same either way. For more details on the recommended PR workflow, see this section of devguide. |
Superseded by #30824 |
Instead of hard-coding the class name in the
__repr__
string, resolve the actual one which makes the__repr__
more subclass friendly.https://bugs.python.org/issue21861