Skip to content
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

Closed

Conversation

beezz
Copy link

@beezz beezz commented Jul 14, 2019

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

@the-knights-who-say-ni
Copy link

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!

@beezz beezz force-pushed the bpo-21861-_io.FileIO-repr-subclass-friendly branch from dc62f03 to 0a02fcb Compare July 14, 2019 11:13
@serhiy-storchaka
Copy link
Member

What about other io classes and the Python implementation (_pyio)?

@beezz beezz force-pushed the bpo-21861-_io.FileIO-repr-subclass-friendly branch 2 times, most recently from 8109726 to 47ed9a3 Compare July 15, 2019 05:36
@beezz
Copy link
Author

beezz commented Jul 15, 2019

@serhiy-storchaka Thanks for your comment. I added remaining classes from the _io module and checked the _pyio implementation which already uses correct class names.

@@ -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]>",
Copy link
Member

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))

Copy link
Contributor

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.

Copy link
Author

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.

@taleinat
Copy link
Contributor

taleinat commented Jul 17, 2019

@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.

@csabella
Copy link
Contributor

csabella commented Feb 6, 2020

@beezz, please address the review comments. Thank you!

@beezz beezz force-pushed the bpo-21861-_io.FileIO-repr-subclass-friendly branch from 47ed9a3 to bd9440e Compare February 13, 2020 15:58
@beezz
Copy link
Author

beezz commented Feb 13, 2020

@beezz, please address the review comments. Thank you!

@csabella Thanks for the comment. I tried to address the requested changes and added the unit tests.

@beezz beezz force-pushed the bpo-21861-_io.FileIO-repr-subclass-friendly branch from bd9440e to 3b80300 Compare February 13, 2020 16:15
Instead of hardcoding the class name in the __repr__ string, resolve the
actuall one which makes the __repr__ more subclass friendly.
Copy link
Contributor

@taleinat taleinat left a 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'
Copy link
Contributor

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(
Copy link
Contributor

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
Copy link
Contributor

@taleinat taleinat Feb 21, 2020

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.)

@bedevere-bot
Copy link

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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

@taleinat
Copy link
Contributor

taleinat commented Feb 21, 2020

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.

@erlend-aasland
Copy link
Contributor

Superseded by #30824

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants