fix: wire --regex-pattern through the CLI (#175) - #180
Closed
patchwright wants to merge 1 commit into
Closed
patchwright wants to merge 1 commit into
patchwright wants to merge 1 commit into
Conversation
patchwright
added a commit
to patchwright/wildlint
that referenced
this pull request
Jun 28, 2026
Distilled from un33k/python-slugify#180: an argparse option whose dest is never read — the flag parses, then silently vanishes. slugify defined --regex-pattern but slugify_params forwarded every namespace field except args.regex_pattern. Low-FP by construction (default tier): - only fires when a sibling dest on the same namespace IS read in-file, so consumption is local and the gap is a genuine oversight (not cross-file use); - a "namespace" is a parse_args() result or a param annotated argparse.Namespace — definitions-only files (e.g. httpie's definition.py) have neither and stay silent; - bails on vars()/getattr/setattr/hasattr/__dict__/parse_known_args namespaces (dests could be consumed by string); - skips help/version actions and dynamic/SUPPRESS dests. Validated: fires exactly once (regex_pattern) on real slugify master; 0 findings across 10 real argparse CLIs (black/flask/pip/aws/pytest/cpython/ youtube-dl/httpie/tenacity/mitmproxy) — httpie went 46->0 after restricting reads to actual namespace variables. 51 tests pass, ruff clean, self-clean. Co-Authored-By: claude-flow <ruv@ruv.net>
Author
Owner
|
This is Dojo, posting a maintainer-authorized follow-up linking this PR to #191. The duplicate CLI regex-forwarding fix is covered in both algorithms, retaining #176's priority and acknowledging the additional regression investigation. The default algorithm remains legacy; improved output rules are opt-in. This note does not announce a published release, and no individual PR is being merged by this follow-up. Thank you for the contribution and discussion. 🚀 Generated with Dojo ⛩️ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #175.
Problem
The CLI defines
--regex-patterninparse_args, butslugify_params()never passesregex_patterntoslugify()— every other argument is wired except that one. So the flag is silently dropped:(@peter-bloomfield reported it; @jdevera confirmed the missing wiring.)
Fix
Add
regex_pattern=args.regex_patternto theslugify_params()dict.argparsealready defaults it toNonewhen the flag is absent, which matchesslugify()'s own default, so existing behavior is unchanged.Tests
regex_patterntoTestCommandParams.DEFAULTSsotest_defaultsnow covers it.test_regex_pattern: the flag flows through to params.test_regex_pattern_end_to_end: reproduces the exact example from --regex-pattern option ignored by CLI #175 and asserts___this-is-a-test___.Both new tests fail on the current
main(KeyError / wrong output) and pass with the fix. Full suite: 84 passed.