False positive `unnecessary-dunder-call` on `__enter__`

[jamesbraza]

Bug description

Here is b.py:

"""b.py"""

# pylint: disable=missing-function-docstring

from collections.abc import Iterator
from contextlib import contextmanager

@contextmanager
def some_context_manager() -> Iterator[None]:
    yield

Here is a.py:

"""a.py"""

# pylint: disable=missing-function-docstring

from unittest.mock import MagicMock, call, patch

from .b import some_context_manager  # pylint: disable=relative-beyond-top-level

def just_enters() -> None:
    # NOTE: the pylint false positive is on the next line: unnecessary-dunder-call
    some_context_manager().__enter__()

@patch(f"{__name__}.some_context_manager")
def test_just_enters(mock_some_context_manager: MagicMock) -> None:
    all_mocks = MagicMock()
    all_mocks.attach_mock(mock_some_context_manager, "some_context_manager")

    just_enters()

    # Known pylint bug, SEE: https://github.com/pylint-dev/pylint/issues/7351
    # pylint: disable-next=unnecessary-dunder-call
    all_mocks.assert_has_calls([call.some_context_manager().__enter__()])

When there is an import of a function decorated with contextlib.contextmanager, and one just calls __enter__ (and not __exit__), pylint will report a false positive unnecessary-dunder-call.

Another comment is the message printed says: "Invoke context manager directly." How else can one invoke a context manager directly, without calling __exit__?

Configuration

No response

Command used

pylint --score=false a.py

Pylint output

************* Module a
a.py:11:4: C2801: Unnecessarily calls dunder method __enter__. Invoke context manager directly. (unnecessary-dunder-call)

Expected behavior

I expect pylint to not have this false positive.

Pylint version

pylint 2.17.2
astroid 2.15.2
Python 3.10.10 (main, Feb 19 2023, 17:57:18) [Clang 14.0.0 (clang-1400.0.29.102)]

OS / Environment

macOS Monterey version 12.6

Additional dependencies

No response

[Taiquan-Liu]

Same false positive behavior when decorated with from contextlib2 import contextmanager.

[Pierre-Sassoulas]

Why would you want to hack a context manager by not calling __exit__ ? Couldn't you do what you want before exiting ?

[jamesbraza]

Yeah @Pierre-Sassoulas firstly don't feel bad closing this, as it is an edge case.

---

My Use Case

Python controls an external machine that can be paused. Pausing functionality was implemented with a context manager, where __enter__ initiates a pause and __exit__ initiates an unpause/resume. A context manager seems like a good choice for the driver, because it designs away the ability to forget an un-pause.

Users are requesting the ability to abort the Python process, and part of the requested abort behavior is to leave the machine paused. In code, this means the abort routine calls __enter__ (and not __exit__, which would unpause).

Does that make sense? Basically my use case is an abort behavior that just acquires a resource.

---

Implications with pylint

pylint should only report unnecessary-dunder-call if both __enter__ and __exit__ are called within a scope, because that's what the with statement is made for.

If just __enter__ is called, maybe unnecessary-dunder-call shouldn't be reported, because the with statement isn't applicable.

[Pierre-Sassoulas]

I'm wondering if in your case it wouldn't make more sense to use two context managers, one for the process, one for pausing the machine, because that way you also don't have to remember to un-pause the machine when you aborted the process.

Regarding the decision on the issue, I'm going to wait for other maintainers opinions. I'm slightly -1 on this because I think it's caused by a hack and it's possible to redesign the code (so not a false positive). Changing the behavior in pylint would encourage to make context managers less convenient by exposing their internals (in particular for beginners not using context managers as intended). It's always possible to disable the check locally if you're an expert with a very good reason to not want to re-design your context manager.

[barisione]

This can be useful if you want to enter a context manager in a function and exit it in another function. For instance, if you define a class with an __enter__ that calls __enter__ for other context managers.

A valid counterargument is to use a contextlib.ExitStack which is true, but then how do you implement something like ExitStack?

Another use case in my code is to patch a method for a 3rd-party library forever using unittest.mock.patch.

[DanielNoord]

I think all of these are cases where you would explicitly disable this message. In general I think you are unlikely to want to call __enter__ or __exit__.
In the class example you could just open the other context managers, use a contextmanager decorator and use a yield.