aio-libs / multidict / 35913343317

87%

push

github

Reject arguments passed both positionally and by name (#1545)

<!-- Thank you for your contribution! -->

## What do these changes do?

`parse2()` in `_multilib/parser.h` enumerated the shapes the keyword
tuple could take, and the shapes where a keyword repeats an argument
already bound positionally were not among them. The surplus arguments
were dropped rather than rejected, so `md.get("a", "b", key="c")`
quietly returned the value for `"a"`, and `add()` was worse:
`md.add("a", key="k", value="v")` read its value out of the first
keyword slot and stored `("a", "k")`.

The enumeration is replaced by a walk over the keyword tuple that binds
each name and rejects one that is already bound, mirroring how CPython
binds arguments for an equivalent `def`, down to reporting the leftmost
offending keyword. That also corrects the arity messages, whose two
`minargs` labels were swapped: methods with an optional second argument
claimed to take exactly one, and `add()` claimed to take a range.

The two parameter names are distinct, so the walk compares the one still
unbound first. Without that, `get(key, default=...)` pays a second
`PyUnicode_CompareWithASCIIString()`, which measured as +4.3% on that
call; ordering it this way brings it back to +0.87%.

Only the C extension is affected. The pure-Python implementation already
raised `TypeError` for every one of these and is unchanged; it served as
the oracle for the expected messages.

## Are there changes in behavior for the user?

Yes. Calls that were silently accepted now raise `TypeError`, matching
the pure-Python backend, and `md.add("a", key="k", value="v")` no longer
stores a wrong value. The wording of some existing `TypeError` messages
changed as a result.

## Is it a substantial burden for the maintainers to support this?

No. `parse2()` is shorter than it was, and the error precedence follows
one rule instead of a case per keyword-tuple shape.

## Related issue number

None.

## Checklist

- [x] I think... (continued)

765 of 1530 branches covered (50.0%)

Branch coverage included in aggregate %.

44 of 46 new or added lines in 1 file covered. (95.65%)

7290 of 7682 relevant lines covered (94.9%)

1.9 hits per line