`PTH*`: Incorrect suggestion to use `Pathlib` when using file descriptors

[MichaReiser]

Multiple pathlib rules recommend the use of pathlib.Path over their os equivalent even when they're used with a bytes string or directory descriptor which aren't supported by pathlib.

One such example is

import os
os.listdir(1)

$ ruff --version
ruff 0.11.7
$ ruff check --isolated --select PTH208 t.py
t.py:2:1: PTH208 Use `pathlib.Path.iterdir()` instead.
  |
1 | import os
2 | os.listdir(1)
  | ^^^^^^^^^^ PTH208
  |

Found 1 error.

Past instances of the same or similar error:

• PTH123 suggest to use pathlib.Path.open() which does not implement opener #7620
• PTH123 suggests Path.open() which does not support file descriptors #12871

[LaBatata101]

I can take all of those, but if anyone wants to take any of the others, feel free to. I'll start with #17691.

[sbrudenell]

I wrote the linked sub-issues.

IMO file descriptor usage shouldn't be conflated with bytes usage.

It's still valid to suggest pathlib.Path in place of a non-pathlib function used with a bytes path.

It's not the case that pathlib somehow supports str and doesn't support bytes. It actually just expects its arguments to be fsdecode()'ed strings.

That's to say, IMO the following should error:

open(b"foo")  # *should* error and suggest Path(fsdecode(b"foo")).open()

In #17705 I see that open(b"foo") is added as a test.

This is a philosophical stance. In my experience, explicitly calling fsdecode() makes it clear where possible platform path encoding issues might arise.

File descriptors are a different access pattern that just doesn't have an analog in pathlib.

[ntBre]

Ah I see, I just tested Path(b"foo") and concluded that it should be included here because it also causes an error.

It does seem reasonable to me still to flag the bytes case if we update the rule docs with an example using fsdecode, but I'm curious what @MichaReiser and @LaBatata101 think too.

Thanks for opening the issues and following up here!

[LaBatata101]

I think that's reasonable, we could even provide a fix for that.

[MichaReiser]

Thanks @sbrudenell for the added context. I only read the pathlib documentation and it stated that byte strings aren't supported.

Let's only change the file descriptor case for now. We need to be more careful about byte strings if we start providing fixes (although they have to be unsafe in most cases anyway because we can't tell in many instances if a path is a file descriptor, string or byte string)

[sbrudenell]

+1 for PTH* to not apply fixes.

I'll mention that part of the type safety of Path over str is that it's effectively a strong type for the filesystem encoding. If you see a Path, it must (or should!) have been derived from fsdecode(), not bytes.decode().

I often find that using Path reminds me to check other, upstream parts of my codebase for encoding issues.

Since converting os calls to pathlib is so instructive for humans, I would find it counterproductive for the machine to do it.