Users might already expect that filter() accepts path-like names, because its docs say:

It is the same as [n for n in names if fnmatch(n, pat)], but implemented more efficiently.

And the fnmatch() docs say:

Both parameters are case-normalized using os.path.normcase()

And the normcase() docs say:

Accepts a path-like object.

So I think we should fix the discrepancy and explicitly support path-like names.

Let's fix it then. I think I'll make it a bugfix rather than a feature.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

I have made the requested changes; please review again. By the way, I'm wondering whether we should explicitly call os.fspath in fnmatchcase actually so that all functions have path-like support:

 def fnmatchcase(name, pat):
     """Test whether FILENAME matches PATTERN, including case. 

     This is a version of fnmatch() which doesn't case-normalize
     its arguments.
     """
     match = _compile_pattern(pat)
-    return match(name) is not None
+    return match(os.fspath(name)) is not None

Thanks for making the requested changes!

@barneygale: please review the changes made to this pull request.

By the way, I'm wondering whether we should explicitly call os.fspath in fnmatchcase actually so that all functions have path-like support

That sounds reasonable to me!

See #123215 (comment) for the rationale of marking it as DO-NOT-MERGE for now.

See #123215 (comment) for the rationale of closing this PR.