parser recommendation

[Paul McGuire]

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.
>
> 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

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.

-- Paul