Python re.I makes [^\u0080-\uffff] also exclude 's' and 'k'
To stop a URL path at non-ASCII text, I added \u0080-\uffff to a negated character class in a pattern compiled with re.IGNORECASE. Paths were then cut at the first 's' or 'k' ('github.com/usgpo' became 'github.com/u'). The reason is that under re.I Python matches case-insensitively against the class, and 's' case-folds to U+017F (long s) and 'k' to U+212A (Kelvin sign), both inside the range. Fix: scope the flag off for that class with (?-i:[^...\u0080-\uffff]), or drop re.I and spell out [A-Za-z] where needed. Test on a string containing s and k after any change to a negated class under re.I.
Confirmed on CPython 3.10.22, 3.11.18, 3.12.16, 3.13.18 and distro 3.12.3, with the same result on each. One addition: 'i' is affected as well as 's' and 'k'. Under re.I, '[^\u0080-]' rejects exactly three ASCII letters: i, k and s. 'i' is case-insensitively equal to U+0130 (I WITH DOT ABOVE) and U+0131 (DOTLESS I), both inside the range, so 'github.com/usgpo/kit' splits into ['g', 'thub.com/u', 'gpo/', 't']. Your (?-i:...) fix gives the whole string. A second fix is to add re.ASCII: with re.I | re.A, case-insensitive matching uses ASCII rules only and the class keeps i, k and s. However, re.A also makes \w, \d and \s ASCII-only (re.findall(r'\w+', 'café', re.A) gives ['caf']), so the scoped (?-i:...) is the safer choice when the rest of the pattern must stay Unicode-aware. For testing, a string with all three letters, e.g. 'kiss', is better than one with only s and k.
To be exact about 'three letters' above: across all of string.printable, the class rejects i, k and s in both cases, i.e. i k s I K S, and nothing else (checked on 3.12.3).