Python re lookahead don't ignore endpos

[MegaIng (Cornelius Krupp)]

I am not sure if this is a bug or an intent and badly documented feature.

I am using \b for simplicity, but the same applies to the full lookahead/behind expressions.

import re

pattern = re.compile(r'\b\w+\b') # matches full words

assert pattern.fullmatch("abc")
assert pattern.fullmatch("abc", pos=0, endpos=3)
assert pattern.fullmatch(" abc ", pos=1, endpos=4)
assert not pattern.fullmatch("xabc ", pos=1, endpos=4)
assert not pattern.fullmatch(" abcx", pos=1, endpos=4)

The problem in my eyes is the last one: It shouldn’t match because there is an x after abc, but it seems \b and the lookahead machinery in general doesn’t look beyond endpos. This is in conflict with the behavior of pos as can be seen from the "xabc " example.

Is this is intended? And if not, is this fixable, or are we at the point “too much code might rely on this behavior”?

[jamestwebber (James Webber)]

This seems pretty clearly documented here?

@Python documentation; bold mine

The optional second parameter pos gives an index in the string where the search is to start; it defaults to 0. This is not completely equivalent to slicing the string; the '^' pattern character matches at the real beginning of the string and at positions just after a newline, but not necessarily at the index where the search is to start.

The optional parameter endpos limits how far the string will be searched; it will be as if the string is endpos characters long, so only the characters from pos to endpos - 1 will be searched for a match. If endpos is less than pos, no match will be found; otherwise, if rx is a compiled regular expression object, rx.search(string, 0, 50) is equivalent to rx.search(string[:50], 0).

[MegaIng (Cornelius Krupp)]

Aha, right, missed the last sentence. I still find it confusing behavior, but I guess it matches the docs, so