René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"SetManager.__contains__ is the lone non-normalizing membership check","articleBody":"After #238's follow-ups on PR #240, `SetManager` normalizes everywhere — `add()`, `remove()`, the constructor, and all set operators apply `lc()` (lowercase, strip leading/trailing periods). `__contains__` is now the single exception:\n\n```python\nfrom nameparser.config import Constants\n\nc = Constants()\n'Dr.' in c.titles        # False — raw membership\nc.titles.remove('Dr.')   # removes 'dr' — normalized\nc.titles \u0026 ['Dr.']       # matches 'dr' — normalized\n```\n\nA user who checks `'Dr.' in c.titles`, sees `False`, and concludes their config never took effect is misled — every other operation on the same value succeeds.\n\nFix options: normalize `str` values in `__contains__` (`lc(value) in self.elements`; the parser's own `lc(piece) in ...` calls are unaffected since `lc` is idempotent), or document raw membership as intended. Normalizing seems right for consistency. Note the ABC comparison mixins (`__le__`, `__eq__`) route through `__contains__`/element iteration, so check those semantics while at it.\n\nFound by review of PR #240 — the asymmetry predates that PR (add/remove already normalized), but the PR widens it: seven operations normalize, one membership check doesn't.","author":{"url":"https://github.com/derek73","@type":"Person","name":"derek73"},"datePublished":"2026-07-06T01:51:10.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/244/python-nameparser/issues/244"}