sre negated lookaheads/behinds

Robin Becker robin at jessikat.fsnet.co.uk
Thu Oct 19 07:25:59 EDT 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
>biting you.
>
>--amk
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?
-- 
Robin Becker



More information about the Python-list mailing list