ANN: pyparsing 1.4.11 released

[Paul McGuire]

On Feb 11, 3:44 am, bearophileH... at lycos.com wrote:
>
> Maybe you can use the "in" instead of "==", meaning that a certain
> string conforms to a certain pattern, that defines an implicit class
> of possibilities, so with the "in" you look if the string is present
> in that class of acceptable patterns, instead of being equal to that
> class.
>
> integers = Word(nums)
> if "123" in integers:
>     # do something
>

I understand your interpretation, but in the pyparsing world thus far,
something named 'integers' would be written as

integers = OneOrMore( Word(nums) )

I think your counterpoint is that, by introducing the concept of using
an operator to perform a matching operation, that that pyparsing
expression is no longer an item being used in a parser, but is an
object representing a class of all possible matching strings, and so
'in' would be more suitable here.

I considered whether overloading the '==' operator might be overdoing
things in the first place.  The alternative is to do something like
adding a match method as re's do, as in:

integer.match("123")

and this could return a ParseResults object or None, which would be
suitable for boolean testing.

Perhaps I was seduced by too much cleverness to add another operator
for this concept.  Perhaps I was taken by a fit of Perlishness.  I
really tried to consider what other uses there might be for '==' with
respect to ParseElement objects, and could only think of improbable
contrivances.  Ultimately, I took the leap and went with '==' - we'll
see how this plays out among the pyparsers out there.

-- Paul