GeezerVison

All commit authors signed the Contributor License Agreement.

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

@picnixz

Thank you for the review. I've addressed the requested changes:

• Moved the path-like tests immediately after their corresponding filter and filterfalse tests.
• Updated the documentation to describe path-like input support and preservation of the original objects.
• Benchmarked the existing itertools.filterfalse implementation against a list comprehension and an explicit loop using pyperf, with input sizes of 10, 100, 1,000, and 10,000 elements.

The list comprehension was consistently the fastest, reducing execution time by approximately 18–21% compared with the previous implementation.

I've updated filterfalse() accordingly and removed the unused itertools import.

All 26 test_fnmatch tests pass, and git diff --check reports no issues.

The benchmark results are preliminary measurements from a CPython 3.16 debug build using pyperf --fast, rather than release-build performance figures.

Documentation build overview

📚 cpython-previews | 🛠️ Build #35785545 | 📁 Comparing 584ec30 against main (44579b0)

  🔍 Preview build  

The benchmark results are preliminary measurements from a CPython 3.16 debug build using pyperf --fast, rather than release-build performance figures.

Please don't. Use a release build or one with a --enable-optimizations. A debug build serves no purpose in benchmarking in general. And please tell me which samples you used.

Thanks for the review. I've pushed the documentation updates and added test_mix_bytes_str_pathlike to both FilterTestCase and FilterFalseTestCase. All 28 test_fnmatch tests pass.

I also reran the performance comparison using a CPython 3.16 release build rather than a debug build.

The benchmark compares three implementations:

• itertools.filterfalse with a lambda predicate
• A list comprehension
• An explicit for loop

The input consists of filename strings matched against *.py. I tested input sizes of 10, 100, 1,000, and 10,000 elements, with matching proportions of 0%, 50%, and 100%.

Selected results:

The list comprehension was faster than the lambda-based implementation in 11 of the 12 tested scenarios. However, some measurements showed substantial variability, so these results should be treated as preliminary rather than definitive.

I haven't yet reproduced the benchmark scripts from the original filterfalse PR. I'll check those as well to ensure the comparison covers the original payloads.

Please don't use an LLM to post your comments. I don't want to communicate with an agent only. YOur comments are not edited at since the markdown contains the HTML itself.

Please avoid updating the branches when there is nothing that has changed. It wastes CI resources. Read https://devguide.python.org/getting-started/pull-request-lifecycle/#update-branch-button

Ok. Thanks for the review. I've addressed the feedback, including the documentation changes and the mixed bytes/str/path-like regression tests.

The latest CI run has completed, with all 51 technical checks passing across the supported platforms.

I also wanted to clarify the earlier branch update: it was intended to retry the macOS CI job after the runner lost communication. I'll avoid unnecessary branch updates going forward.

The PR should now be ready for another review.

I pushed the requested changes in b55db66, including the list comprehension in filter(), and resolved the addressed review threads. Tests, lint, and the documentation preview have all passed.

Ok, sorry I misunderstood. I restored the original POSIX optimization in filter() while retaining PathLike support through os.fspath(). All 28 test_fnmatch tests pass locally.

No, the change in filtrr was right. I did not want to change it to a list comprehension unless it is faster. That was the only comment.