-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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 consider-using-with
for class member variable
#4808
Comments
consider-using-with
for class member variable
Can you give an example where it triggers for a context manager? As for the original question: that may be just because you gave a simplified example, and not as straightforward for your real code, but in this case I would propose the following code: class dataWrapper:
def __init__(self, file_name):
self.file_name = file_name
def __iter__(self):
with open(self.file_name, encoding="utf8") as file_handle:
yield from file_handle It's shorter, the resource is only open as long as necessary for reading, and closing the resource is not bound to the garbage collector and how the end user uses the |
So, to give a more accurate version that uses a temp directory and some processed input data:
This can be written using 2 nested withs and a yeild in the iter function, but (to me) feels cleaner when done in the init. Obviously the linter disagrees. One argument in favour of this is that the processing may fail, which should probably be handled in the init rather than iter. I'm aware that this won't be cleaned up until the last strong reference is gone, (in my application) this file is a server response, so will be a very short lived file. RE context manager, I believe it's a detail of implementation, rather than a detail of encapsulation. |
Thanks for the more detailed example. The thing is that I don't really know how we should detect this (I would argue) rather special case without disabling this check for class members completely. Which would mean losing more than we would gain. Ultimately the refactoring messages will always be a bit opinionated, even if they try to promote things which are commonly seen as "best practice". There may be cases where one simply disagrees with this definition, or has a concrete example where following this best practice is just not practicable. In this case I think it is totally fine to disable a check for a specific class (or completely if necessary). This does not mean I am not open to suggestions. If you have an idea how we could fix this "false-positive" while still keeping the check intact for the intended use cases, I am happy to hear it. |
Thank you for your answer/thoughts. I'll leave it for now, as you're right it's a relatively small use case. I've ignored the specific warnings in the necessary location. |
Bug description
Configuration
No response
Command used
Pylint output
Expected behavior
In the case of a member variable where the lifetime of the class is intended to match the lifetime of the associated resources (RAII), I think this warning is unnecessary and incorrect.
The case I've given is trivial. I'm using a temporary folder to do some processing, output a temporary file, stream the file as a server response, then close and delete both file and folder.
My personal use case is similar to the above, but this warning also triggers when writing a context manager (ie with enter/exit functions). I've currently completely disabled this warning, ideally I'd like to either disable for classes or on member variables (I've not found that this is possible).
Based on discussion in #4748, in particular that "The intention of this message is to inform the user that he is doing something which shifts the responsibility of freeing the allocated resources to somebody else", in this case the responsibility isn't being shifted.
Pylint version
OS / Environment
Debian
Additional dependencies
No response
The text was updated successfully, but these errors were encountered: