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

[PT013] Rationale is unconvincing. #11247

Closed
randolf-scholz opened this issue May 2, 2024 · 3 comments · Fixed by #11255
Closed

[PT013] Rationale is unconvincing. #11247

randolf-scholz opened this issue May 2, 2024 · 3 comments · Fixed by #11255

Comments

@randolf-scholz
Copy link

Rule PT013 seems arbitrary. The rationale states:

pytest should be imported as import pytest and its members should be accessed in the form of pytest.xxx.yyy for consistency and to make it easier for linting tools to analyze the code.

But the same reasoning "make it easier for linting tools to analyze the code" could be applied to any library.

What are some concrete linting tools this applies to? If it makes no difference to ruff, should this be enabled by default in ruff?

@charliermarsh
Copy link
Member

Yeah, I'm going to remove that piece from the rationale -- it makes no difference to Ruff. I don't want to go as far as to remove or deprecate the rule, since it can be useful to enforce this convention (and I did some code search -- several large projects do enable this rule), but we should reframe the rationale.

(Note that this rule isn't enabled by default in Ruff; you have to enable the PT category or PT013.)

@randolf-scholz
Copy link
Author

and I did some code search -- several large projects do enable this rule

But is it cargo cult programming, or is there an actual good reason for it nowadays?

The rest of the PT-rules all look very sensible.

@DanielYang59
Copy link

DanielYang59 commented Aug 29, 2024

Thanks for the helpful discussion, I happen to have similar question.

I don't want to go as far as to remove or deprecate the rule, since it can be useful to enforce this convention (and I did some code search -- several large projects do enable this rule)

Not sure if we could/should set some exceptions for approx for example (even pytest document use from pytest import approx), or only check certain patterns that is considered unconventional (for example from pytest import raises/mark/fixture/...). Because approx is heavily and repeatedly used for numerical comparisons materialsproject/pymatgen#4022, and pytest.approx could be very verbose under such scenario.

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 a pull request may close this issue.

3 participants