parser recommendation

[Filipe Fernandes]

On Tue, Jun 3, 2008 at 10:41 AM, Paul McGuire <ptmcg at austin.rr.com> wrote:
> If you learn both, you may find that pyparsing is a good way to
> quickly prototype a particular parsing problem, which you can then
> convert to PLY for performance if necessary.  The pyparsing prototype
> will be an efficient way to work out what the grammar "kinks" are, so
> that when you get around to PLY-ifying it, you already have a clear
> picture of what the parser needs to do.
>

Thanks (both Paul and Kay) for responding.  I'm still looking at Trail
in EasyExtend and pyparsing is very nicely objected oriented but PLY
does seems to have the speed advantage, so I'm leaning towards PLY

But I do have more questions... when reading the ply.py header (in
2.5) I found the following paragraph...

# The current implementation is only somewhat object-oriented. The
# LR parser itself is defined in terms of an object (which allows multiple
# parsers to co-exist).  However, most of the variables used during table
# construction are defined in terms of global variables.  Users shouldn't
# notice unless they are trying to define multiple parsers at the same
# time using threads (in which case they should have their head examined).

Now, I'm invariably going to have to use threads...  I'm not exactly
sure what the author is alluding to, but my guess is that to overcome
this limitation I need to acquire a thread lock first before
"defining/creating" a parser object before I can use it?

Has anyone ran into this issue....?  This would definitely be a
showstopper (for PLY anyway), if I couldn't create multiple parsers
because of threads.  I'm not saying I need more than one, I'm just not
comfortable with that limitation.

I have a feeling I'm just misunderstanding since it doesn't seem to
hold you back from creating multiple parsers under a single process.

filipe