sre negated lookaheads/behinds
robin at jessikat.fsnet.co.uk
Thu Oct 19 13:25:59 CEST 2000
In article <3dpukxdae9.fsf at kronos.cnri.reston.va.us>, Andrew Kuchling
<akuchlin at mems-exchange.org> writes
>Robin Becker <robin at jessikat.fsnet.co.uk> writes:
>> Clearly my a( is not preceded by self. in either case. However, in the
>> first case as there is not enough room for the positive look behind I
>> think it is wrongly failing to match. Is this correct?
>I think you've found a bug. (First bug found in 2.0?) The ASSERT_NOT
>opcode contains this bit of code:
> if (state->ptr < state->beginning)
> return 0;
>I think this is wrong; if the pattern is too long to match, then
>clearly the negative lookbehind succeeds, so it should simply continue
>matching the rest of the pattern. Patch #101972 on SourceForge is a
>proposed fix; /F has to approve it first.
>> I know the documentation mentions that the (?< ... ) patterns must be
>> fixed length, but nowhere does it say that negated patterns must be
>> fixed length.
>Er, yes, the docs do in fact say that. But that isn't the problem
I have no wish to be known as the bug finder general :)
Anyhow as for the documentation my intention was to make clear that
negated patterns are in general variable length ie they match anything
that doesn't match the given pattern. I suppose it's an implementation
issue why the condition patterns have to be fixed length or is it some
restriction on the re language?
As for sourceforge I can't seem to get access to login right now. Any
one else having trouble?
More information about the Python-list