-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Extract AbstractSandbox._mk_*
methods
#4099
Conversation
AbstractSandbox._mk_*
as static methodsAbstractSandbox._mk_*
methods
I find it annoying that code that was previously perfectly-valid Python is no longer allowed. I see now that these functions were used locally-only and ignored for their presence in the class. I wonder if the Python language has an opinion on this usage. That is, I'd really like to see an upstream reference (ideally in Python and not just mypy) that clarifies why this usage is discouraged and acknowledges/justifies the weakness(es):
On the other hand, it does appear as if staticmethod is the default condition:
It really feels to me like mypy is broken here, and unless there's upstream guidance as to why the existing form is disallowed or discouraged, let's just suppress the mypy errors with |
I'm also fine keeping this suppressed in #3979 at the moment. |
…ctSandbox-static-methods
I'll close this for now, can be re-opened if reconsidered |
Summary of changes
Prompted by #3979 (comment) . This seems to be the most sensible fix. Outside of a
type: ignore
.Pull Request Checklist
newsfragments/
. (no user-facing changes)(See documentation for details)