Detect improvable code with open + pathlib.Path

[kasium]

Current problem

In the python world. developers tend to use both the old os.path based system and pathlib in parallel. This can lead to some confusion.
Recently I've seen some code like this:

from pathlib import Path
path = Path("foo")
with open(str(path)) as handle:
  pass

Desired solution

Since open can consume a Path object, the above code can be improved to open(path) or path.open()

Additional context

I'm not 100% sure if this is in the scope of pylint, but calling str over and over again will lead to a worse performance (even if not too much). Therefore I see such a check as a benefit.
I'm also happy to open a PR, if the idea is accepted.

[Pierre-Sassoulas]

I'm not 100% sure if this is in the scope of pylint,

Pylint has inference so this is the king of check it could do :) I like the check: even if it's not life changing, it's a nice little clean-up / small perf increase. We could even make it a default one instead of a code style but maybe that's pushing it a little, I'll wait for other opinion on this.

[Pierre-Sassoulas]

What do you think @cdce8p ? On the one hand it about type and we're not mypy, but on the other hand it "feel" like a pylint check.

[cdce8p]

What do you think @cdce8p ? On the one hand it about type and we're not mypy, but on the other hand it "feel" like a pylint check.

The way I see it, it should be fine. We wouldn't do any type checking. At least what I understand, it would be more a simple check for str(path) inside open(...) calls.

The question I would ask though is if it's such a common issue that we need a check for it. Maybe there are 1-2 of these cases in a codebase. I'm not sure the extra maintenance would be worth it. My vote would be to close this issue.

[Pierre-Sassoulas]

it would be more a simple check for str(path) inside open(...) calls.

I think we'd have to check the type of path in str(path). If path is a pathlib.Path then it can be simplified, but for a custom class that has a __str__ returning a path as a string which will not be handled correctly by open the str call might be justified.

class MyCustomPath:
    def __init__(self, base, name):
        self.base = base
        self.name = name

    def __str__(self):
        return f"{self.base}/{self.name}"


with open(str(MyCustomPath(".", __file__)), "r") as f:
    print(f.read())
with open(MyCustomPath(".", __file__), "r") as f:
    print(f.read())

[jacobtylerwalls]

Cases like this are fine, since the function has no control over the input. This is what astroid is good at telling us--whether all the inferred values are a pathlib.Path.

def read_helper(input: Any):
    with open(str(input)) as f:
        ...

I like the idea of the check. Should be simple to implement.