Repository navigation
fnmatch.filter and filterfalse work with pathlikes only on non-Posix platforms #160900
Description
fnmatch.filter contains a check:
if os.path is posixpath:
# normcase on posix is NOP. Optimize it away from the loop.
It calls normcase on the paths to be filtered only on non-Posix platforms.
The check dates from 2001 and the comment was probably true then. But nowadays, os.path.normcase does do something even on Posix: it normalizes path-like objects into strs or bytes.
So on MacOS I get:
>>> import fnmatch
>>> from pathlib import Path
>>> fnmatch.filter([Path("hi")], "hi")
Traceback (most recent call last):
File "<python-input-2>", line 1, in <module>
fnmatch.filter([Path("hi")], "hi")
~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
File "/Users/jelle/py/cpython/Lib/fnmatch.py", line 61, in filter
if match(name):
~~~~~^^^^^^
TypeError: expected string or bytes-like object, got 'PosixPath'
But this will work on Windows.
I think this is should be fixed for two reasons:
- It's an unnecessary difference in behavior between platforms. Python should work the same across OSes as much as possible, and there's no good reason for the behavior to differ here.
- In general, we want path-related functions to accept path-like objects (PEP 519)
However, we've generally treated PEP 519 changes as new features, so let's change this on main only.
Discovered in python/typeshed#16647
Activity
picnixz commentedon Oct 29, 2026
Yeah, this is somethign I found when I implemented filterfalse but I was afraid to change the implementation. I don't think we need this small optimization anymore.
zedzhen commentedon Oct 29, 2026
fnmatch.fnmatch normalizes both parameters (this is explicitly stated in the documentation), and the documentation says
pythongh-160900: add NEWS entry