Variable-width lookbehind

[OKB (not okblacke)]

For years now Python has not supported variable-length lookbehinds.
I'm just curious whether there are any plans to change this in Python
3.0, or before, or after. It seems that Perl 6 will allow variable-
width lookbehinds (see http://dev.perl.org/perl6/doc/design/apo/A05.html
and http://dev.perl.org/perl6/rfc/72.html ).

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Paul Rubin]

For years now Python has not supported variable-length lookbehinds.

I'm not sure what that is and the perl links you gave don't work, but
it sounds evil. Basically it sounds like an even uglier form of
regexp backtracking than what we have now. Regexps are just not the
right framework for implementing such complex parsers. We should
instead have some more general parser library instead of keeping on
jamming more crap into regexps. There's a famous Zawinski quote that
I won't repeat here since I don't want to wear it out.

 

[OKB (not okblacke)]

I'm not sure what that is and the perl links you gave don't work,
but it sounds evil.

The links work fine for me. . .

You're not sure what "variable-length lookbehinds" means?
Lookbehind is something that Python regexps already have. You can do
"(?<=one)two" to match "two" only if it's preceded by "one", and you can
do "(?<!one)two" to match "two" only if it's NOT preceded by "one".
What you can't do is "(?<=one|three)two", because Python requires that
the lookbehind contain only strings of a fixed length. What I'm asking
about is the possibility of lifting this limitation, to allow the
lookbehinds (positive and negative) to contain general regexps. I don't
see how this is in any way evil.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Gary Herron]

Paul Rubin wrote:



The links work fine for me. . .

You're not sure what "variable-length lookbehinds" means?
Lookbehind is something that Python regexps already have. You can do
"(?<=one)two" to match "two" only if it's preceded by "one", and you can
do "(?<!one)two" to match "two" only if it's NOT preceded by "one".
What you can't do is "(?<=one|three)two", because Python requires that
the lookbehind contain only strings of a fixed length. What I'm asking
about is the possibility of lifting this limitation, to allow the
lookbehinds (positive and negative) to contain general regexps. I don't
see how this is in any way evil.

If not *evil*, then how about *unreadable*. Regular expressions are
powerful, but nearly unreadable as they are. Allowing them to be even
more complex just gets one step closer to *absolutely unreadable*.

But that's not necessarily a reason to keep it out of the language.
(Well actually, keeping Python's clarity-of-code goal in mind, it might
be reason enough for some to want to keep it out.) But this is an all
volunteer community. Your feature is not in the language because no one
has cared enough to implement it. Or if some one has implemented it, no
one has found it useful enough to lobby it into the language.

Are you willing to implement it and lobby for it's inclusion? If so,
good, we'll look at it. If not, then perhaps you understand perfectly
why it's not yet included.

Welcome to the world of Open Source!

Gary Herron

 

[OKB (not okblacke)]

If not *evil*, then how about *unreadable*. Regular expressions
are powerful, but nearly unreadable as they are. Allowing them to
be even more complex just gets one step closer to *absolutely
unreadable*.

Well, it doesn't really change the potential for unreadability. It
just allows people to put existing unreadable (or readable) regexps
inside a particular kind of group.

Are you willing to implement it and lobby for it's inclusion? If
so, good, we'll look at it. If not, then perhaps you understand
perfectly why it's not yet included.

Yeah, this is what I was expecting, and it's a valid point. I was
just wondering if this had ever been floated before. I personally have
nowhere near the chops to write something like a regex engine (that's
why I like using Python -- it's got one built in!).

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown

 

[Tim Roberts]

For years now Python has not supported variable-length lookbehinds.
I'm just curious whether there are any plans to change this in Python
3.0, or before, or after. It seems that Perl 6 will allow variable-
width lookbehinds (see http://dev.perl.org/perl6/doc/design/apo/A05.html
and http://dev.perl.org/perl6/rfc/72.html ).

If I may be just a bit catty, your last sentence may actually be the best
reason NOT to include it in Python 3.0. Perl 6 has become a worthy
successor to ALGOL 68 and PL/I. They are attempting to pack in every
feature that has ever been requested by every person in the known universe.

 

[OKB (not okblacke)]

If I may be just a bit catty, your last sentence may actually be
the best reason NOT to include it in Python 3.0. Perl 6 has become
a worthy successor to ALGOL 68 and PL/I. They are attempting to
pack in every feature that has ever been requested by every person
in the known universe.

That's as may be, but if I may be a bit redundant with myself, I'd
like to reiterate that I don't see this is as a new "feature". Regular
expressions already exist in Python. Lookbehinds already exist in
Python regular expressions. The only thing that doesn't exist is the
ability to use arbitrary regular expressions in lookbehinds, and my
understanding is that this is just because regular expression engines
have typically been implemented in a way that makes this hard to add on.
In other words, what I'm describing isn't an extension of what regular
expressions are, it's just the lifting of a bothersome implementation-
based restriction on one aspect of their use.

--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is
no path, and leave a trail."
--author unknown