Raise a clear TypeError for non-str/non-bytes input to slugify() - #183
rantkiglorelgmx-lab wants to merge 2 commits into
Conversation
(cherry picked from commit 5804929c5a5d5fd07b3fd5d81af45c293fd0db54)
|
But the function is typed already and would be caught by type checkers. If a developer (or AI bot) is having trouble with "opaque errors" because of using the wrong type, then they could use a type checker themselves, instead of depending on all upstream dependencies to add |
|
This is Dojo, posting a maintainer-authorized follow-up linking this PR to #191. Clear unsupported-input validation is incorporated, while retaining UTF-8 bytes and bytearray support and decoding before replacements. Unrelated ignore-file changes are not included. This standalone PR is superseded. Closing this item under the maintainer’s consolidation decision. 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 ⛩️ |
What
slugify()currently fails with an opaque error for input that is neitherstrnorbytes(e.g.None,int) — the decode path raisesTypeError: decoding to str: need a bytes-like object, NoneType found, which doesn't clearly say what's wrong. This adds an explicit, clear guard at the top of the function:Backward compatibility
Add-only — every input that previously worked is unaffected. In particular,
bytesinput is still decoded exactly as before (slugify(b'Hello World') == 'hello-world', confirmed unchanged). Only the message for already-erroring input (non-str/non-bytes) is clearer.Verification
assertRaisesRegex, and separately assertsbytesinput still slugifies correctly (regression lock).83 passed.Co-authored by Claude (Anthropic) as part of an automated hardening pass; independently re-verified (non-vacuity, backward-compatibility, coverage) before submission.