Users might already expect thatfilter() accepts path-likenames, because its docs say:

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

And thefnmatch() docs say:

Both parameters are case-normalized usingos.path.normcase()

And thenormcase() docs say:

Accepts apath-like object.

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

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 phraseI 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 callos.fspath infnmatchcase 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 callos.fspath infnmatchcase 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.