Encode disallowed characters around already percent-encoded triples

[gaoflow]

Problem

Reserved ({+var}) and fragment ({#var}) expansion is supposed to preserve already valid percent-encoded triples while still percent-encoding any other disallowed characters (RFC 6570 Section 3.2.3).

Operator._only_quote_unquoted_characters does this with an all-or-nothing check: if urllib.parse.unquote(value) != value (i.e. any triple is present) it returns the value untouched, which also skips encoding every other disallowed character.

>>> from uritemplate import URITemplate
>>> URITemplate("{+v}").expand(v="a b%20c")
'a b%20c'        # space left raw; expected 'a%20b%20c'
>>> URITemplate("{#v}").expand(v="x y%20z")
'#x y%20z'       # expected '#x%20y%20z'

This is a regression introduced by the fix for #99, which addressed the opposite problem (valid triples being double-encoded).

Fix

Quote the value segment by segment: pass valid percent-encoded triples through verbatim and percent-encode the text between them. Output is identical for values with no triples or with only triples, so existing behavior is preserved — all current tests still pass, and the new case is now correct:

>>> URITemplate("{+v}").expand(v="a b%20c")
'a%20b%20c'
>>> URITemplate("{+v}").expand(v="a%2Fb c")   # uppercase triple kept, space encoded
'a%2Fb%20c'

Tests

Added test_reserved_expansion_encodes_around_pct_triples. It fails on the current code (a b%20c → a%20b%20c) and passes with the fix; the full suite (59 tests) is green. black, isort, and mypy are clean.

[sigmavirus24]

Suggested change

	_PERCENT_ENCODED: t.Final["re.Pattern[str]"] = re.compile("%[0-9A-Fa-f]{2}")
	_PERCENT_ENCODED: t.Final[re.Pattern[str]] = re.compile("%[0-9A-Fa-f]{2}")

Furthermore, this does not check for whether or not the percent encoding is a valid percent encoding. This just checks if it looks like one. Text that doesn't have a valid percent encoding could still be confused here.

[gaoflow]

Applied the annotation suggestion, thanks.

On the validity point: you're right that the regex only matches things shaped like a pct-triple rather than verifying intent, but that look-alike pass-through is what RFC 6570 specifies for reserved ({+}) and fragment ({#}) expansion. §3.2.3 copies pct-encoded triples through unchanged, and the pct-encoded = "%" HEXDIG HEXDIG production is purely syntactic, so an already-encoded %41 is meant to be passed as-is. The library already did this for a bare "%41"; the bug here is that a following disallowed character caused the whole tail (triple included) to be re-encoded, which contradicts that same rule. So the change narrows behavior back to the RFC rather than adding new look-alike matching.

Strict validation (encode %XX that isn't a 'real' encoding) would be a deliberate divergence from reserved-expansion semantics and its own change - happy to open a separate issue if you'd want to explore that.