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

Catch-all for unhandled events #186

Closed
wants to merge 3 commits into from

Conversation

hifi
Copy link

@hifi hifi commented Jun 10, 2021

Ignoring pong as it is actually handled but the event is still
passed along.

Fixes #185

Ignoring pong as it is actually handled but the event is still
passed along.

Fixes jaraco#185
irc/client.py Outdated
@@ -918,6 +918,8 @@ def _handle_event(self, connection, event):
matching_handlers = sorted(
self.handlers.get("all_events", []) + self.handlers.get(event.type, [])
)
if len(matching_handlers) == 0 and event.type != "all_raw_messages" and event.type != "pong":
Copy link
Owner

Choose a reason for hiding this comment

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

It's starting to look like 'pong' and 'all_raw_messages' aren't special conditions. I wonder if there's a way that 'pong' could not be treated as a special condition (possibly by having a handler added by default). Can you add a comment explaining why "all_raw_messages" should be ignored?

Copy link
Author

Choose a reason for hiding this comment

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

I originally used this downstream to only handle "really" unhandled events and all_raw_messages created duplicate events of things that were already handled as their non-raw versions.

Technically I suppose this could be moved to implementation of the handler to filter out events it doesn't want to handle so it's up to the user.

Pong is special because it is handled already so making the auto-pong an actual handler instead of doing it internally would probably be the right way.

@jaraco
Copy link
Owner

jaraco commented Jun 28, 2021

Have you considered adding tests for this behavior? This library has historically been pretty bereft of tests, but it would be nice to work toward more test coverage. Otherwise, these lines could be removed and tests would still pass.

@hifi
Copy link
Author

hifi commented Jun 29, 2021

I can write tests if they work in the first place. 😄

@jaraco
Copy link
Owner

jaraco commented Jul 16, 2021

Yes, it seems the tests started failing spontaneously, since the last commit before your contrib passed tests just fine. I've fixed the tests failing at main, so I'll re-open this PR to re-run the tests.

@jaraco jaraco closed this Jul 16, 2021
@jaraco jaraco reopened this Jul 16, 2021
@jaraco
Copy link
Owner

jaraco commented Jul 16, 2021

It looks like the remaining test failures are nitpicky linters. I can fix that by running 'black' on the codebase.

Copy link
Owner

@jaraco jaraco left a comment

Choose a reason for hiding this comment

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

Tests are passing again. Can you add a test to capture the expectation added by this change?

@hifi
Copy link
Author

hifi commented Sep 2, 2021

Right, sorry, I need to come around back to this when I continue refactoring again.

@jaraco
Copy link
Owner

jaraco commented Jul 15, 2022

Feel free to re-engage on this issue at your leisure. In the meantime, I'll close the PR.

@jaraco jaraco closed this Jul 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Implement default handler if nothing matches
2 participants