-
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
False positive PLE0302 with special methods as properties. #15572
Comments
I think it seems reasonable to skip the check when there's a property decorator (or maybe any decorator). |
I assume I'm lacking understanding. Can async def __aenter__(self):
return await self._c.__aenter__()
async def __aexit__(self, exc_type, exc_value, traceback):
return await self._c.__aexit__(exc_type, exc_value, traceback) |
@charliermarsh That would require duplicating type hints for the parameters. The return type might not be necessary (Pyright can infer that flawlessly), but the same cannot be said about parameter types. |
Using properties here has multiple benefits, from better automatic type inference to better runtime behavior. With using methods, this would be multiple awaits for a simple wrapper or require |
This might be better to hold off on for now, there are enough static analysis tools that are getting subtle things wrong about dunder methods as descriptors beyond what is visible here that it may still be beneficial to nudge people to slightly different solutions even at a small runtime or legibility cost to ensure their tooling has the expected benefits. |
Example code that works at runtime and which type checkers do understand
Code sample in pyright playground
Rewriting
ExecuteWrapper
as:for contrast has better runtime behavior (slightly, anyhow), but unfortunately, properties are not generic in the type system, so this ends up not type-checked, though ruff has no issue with this definition.
The text was updated successfully, but these errors were encountered: