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

Add TRIO106 rule #8468

Closed

Conversation

karpetrosyan
Copy link
Contributor

Summary

This PR is a part of #8451 and adds TRIO106 rule.

Examples

Bad

import trio as asyncio

Bad

from trio import move_on_after

Good

import trio

Copy link
Contributor

github-actions bot commented Nov 3, 2023

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

@zanieb
Copy link
Member

zanieb commented Nov 3, 2023

I'm not sure this limitation exists in Ruff. I believe we can detect the renamed import when determining if trio is being used.

@charliermarsh
Copy link
Member

Yeah we can actually detect from trio import foo as bar, import trio as foo, etc.

@karpetrosyan
Copy link
Contributor Author

I'm not sure this limitation exists in Ruff. I believe we can detect the renamed import when determining if trio is being used.

I am not sure I understand what you mean here.

@charliermarsh
Copy link
Member

@karpetrosyan - It seems like this rule exists in flake8-trio because flake8-trio needs trio to be imported as trio -- as in, import trio rather than import trio as foo.

In Ruff, we abstract that away. Whenever you use resolve_call_path, we resolve aliases. So if the user does import trio as foo; foo.do_trio_thing(), we'd understand that foo.do_trio_thing() is a reference to trio.do_trio_thing.

In other words, it seems like the limitation that exists in flake8-trio doesn't apply to Ruff, and so the rule wouldn't be needed. Does that make sense?

@karpetrosyan
Copy link
Contributor Author

Yes, that makes perfect sense. Thanks @charliermarsh !

I am new to Ruff, so sorry if this PR was useless. Do I need to close it?

@charliermarsh
Copy link
Member

@karpetrosyan - Not at all, no need to apologize! On the contrary, I'm sorry that you invested time in it. Yes, we can close the PR, since the rule doesn't seem relevant here.

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.

3 participants