Re: New pattern-matching library (was: str.split with multiple individual split characters)

On Mon, Feb 28, 2011 at 8:04 AM, Mike Meyer <mwm-tkOQc4lHIczYtjvyW6yDsg@public.gmane.org> wrote:
> Ok, with everyone at least noticing that regular expressions are hard,
> if not actively complaining about it (including apparently Larry wall),
> maybe it's time to add a second pattern matching library - one that's
> more pythonic?
>
> There are any number of languages with readable pattern matching -
> Icon, Snobol and REXX all come to my mind. Searching pypi for "snobol"
> reveals two snobol string matching libraries, and I found one on the
> web based on icon.
>
> Possibly we should investigate adding one of those to the standard
> library, along with a cross-reference from the regexp documentation?

It's been tried before without much success. I think it may have been
a decade ago that Ka-Ping Yee created a pattern matching library that
used function calls (and operator overloading? I can't recall) to
generate patterns -- compiling to re patterns underneath. It didn't
get much use.

I fear that regular expressions have this market cornered, and there
isn't anything possible that is so much better that it'll drive them
out.

That doesn't mean you shouldn't try -- I've been wrong before. But
maybe instead of striving for stdlib inclusion (which these days is
pretty much only accessible for proven successful 3rd party
libraries), you should try to create a new 3rd party pattern matching
library. While admittedly this gives it a disadvantage to the re
module, I really don't think we should experiment in the stdlib, since
the release cycle and backwards compatibility requirements make the
necessary experimentation too cumbersome.

On the third hand, I could see this as an area where a pure
library-based approach will always be doomed, and where a proposal to
add new syntax would actually make sense. Of course that still has the
same problems due to release time and policy.

-- 
--Guido van Rossum (python.org/~guido)