[issue13998] Lookbehind assertions go behind the start position for the match

2012-02-29 Thread Ezio Melotti
Ezio Melotti added the comment: IMHO the documentation is fine as is. Using pos in combination with lookarounds that match on the beginning/end of the "slice" seems a rather uncommon corner case, and I don't think it's worth documenting it. Even if it was documented, as a user, I would just

[issue13998] Lookbehind assertions go behind the start position for the match

2012-02-13 Thread Devin Jeanpierre
Devin Jeanpierre added the comment: If it's intended behaviour, then I'd request that the documentation specifically mention lookbehind assertions the way it does with "^". Saying "it's slightly different" doesn't make clear the ways in which it is different, and that's important for people w

[issue13998] Lookbehind assertions go behind the start position for the match

2012-02-13 Thread Matthew Barnett
Matthew Barnett added the comment: The documentation says of the 'pos' parameter "This is not completely equivalent to slicing the string" and of the 'endpos' parameter "it will be as if the string is endpos characters long". In other words, it starts searching at 'pos' but truncates at 'endp

[issue13998] Lookbehind assertions go behind the start position for the match

2012-02-12 Thread Devin Jeanpierre
New submission from Devin Jeanpierre : compiled regex objects' match method offers an optional "pos" parameter described to be roughly equivalent to slicing except for how it treats the "^" operation. See http://docs.python.org/library/re.html#re.RegexObject.search However, the behavior of loo