Skip to content

Conversation

@calluw
Copy link
Contributor

@calluw calluw commented Dec 30, 2019

Unix read pipe (from Lib:asyncio.unix_events) is missing is_reading() method available for other read transports within the asyncio protocol, which checks that the transport read is not
paused or the transport is not closing.

This behaviour is documented in Doc/library/asyncio-protocol.rst.

Additional tests for the Lib:asyncio.unix_events module which check against the state of the pipe and the behaviour of is_reading(). New testing harness for functional testing of the UNIX pipe connection and associated methods, with an initial test for the new is_reading() implementation.

This is a fresh rebase PR, based on changes made in the original PR (#17042).

https://bugs.python.org/issue38314

Callum and others added 4 commits December 30, 2019 13:48
Unix read pipe is missing method available for other read transports
within the aynscio protocol, which checks that the transport read is not
paused or the transport is not closing.
Co-Authored-By: Kyle Stanley <aeros167@gmail.com>
Copy link
Contributor

@aeros aeros left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @CallumQuick, sorry for the delay on this PR. I think I can spend some time during the sprint reviewing it though and hopefully getting it merged (assuming you're also currently available and interested).

The implementation is perfectly fine. The test logic is also reasonable at a glance, but I do think that we should definitely group them in test_unix_events.py under something like the existing UnixReadPipeTransportTests (or its own class if needed) rather than in a separate test file. IMO, it doesn't make sense to separate out/add a new test file just for _UnixReadPipeTransport.is_reading() when the other existing unix pipe tests are in test_unix_events.

Is there a particular reason as to why you went with the current approach of having a separate test file?

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

@LewisGaul
Copy link
Contributor

Is there a particular reason as to why you went with the current approach of having a separate test file?

@aeros It looks like this was in reponse to #17042 (comment)?

@calluw
Copy link
Contributor Author

calluw commented Oct 21, 2020

Hi @aeros, yes this was in response to #17042 (comment), suggesting that splitting off the new style of functional tests would be preferable. I also added a simple mock-based test case to test_unix_events as well to round it out whilst the transition takes place.

@aeros
Copy link
Contributor

aeros commented Oct 21, 2020

It looks like this was in reponse to #17042 (comment)?

Oh sorry about that, I think I saw that comment from Andrew ~a year ago when I had made a suggestion for the news entry, but it must have slipped my mind when was looking over this PR. I'll take another pass over the tests.

@aeros aeros self-requested a review October 21, 2020 23:50
Comment on lines +24 to +27
"""
Verify that transports on Unix can facilitate reading and have access to
all state methods: verify using class internals
"""
Copy link
Contributor

@aeros aeros Oct 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Style nit: As per PEP 257, within the standard library, we use the following format for all docstrings:

"""..."""

or

"""...
...
"""

Rather than:

"""
...
"""

I was originally hesitant to point it out for a new test file that doesn't have an existing convention, but during this year's virtual core dev sprint (Oct. 19 - 23), I asked in the general chat and Guido commented that he was "unwaveringly in favor" of using the PEP 257 docstring conventions.

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.

6 participants