parser recommendation

[Filipe Fernandes]

> On Jun 3, 12:34 pm, "Filipe Fernandes" <fernandes... at gmail.com> wrote:
>> On Tue, Jun 3, 2008 at 10:41 AM, Paul McGuire <pt... at austin.rr.com> wrote:
>> 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.
>>

On Tue, Jun 3, 2008 at 1:53 PM, Kay Schluehr <kay.schluehr at gmx.net> wrote:
> Nope. It just says that the parser-table construction itself relies on
> global state. But you will most likely build your parser offline  in a
> separate run.

Thanks Kay for the context.., I misunderstood completely, but your
last sentence coupled with a few running examples, cleared things
right up...

On Tue, Jun 3, 2008 at 4:36 PM, Paul McGuire <ptmcg at austin.rr.com> wrote:
> You can use pyparsing from any thread, and you can create multiple
> parsers each running in a separate thread, but you cannot concurrently
> use one parser from two different threads.  Some users work around
> this by instantiating a separate parser per thread using pickle to
> quickly construct the parser at thread start time.

I didn't know that pyparsing wasn't thread safe.  I kind of just
assumed because of it's OO approach.  Thanks for the work around.  I
haven't given up on pyparsing, although I'm now heavily leaning
towards PLY as an end solution since lex and yacc parsing is available
on other platforms as well.

Thanks Kay and Paul for the advice...  I'm still using the first two I
started looking at, but I'm much for confident in the choices made.

filipe