I agree that focusing on pickling might be a sensible way to go about it. Specifically, make it so that the instance returned by lex() and yacc() can be pickled as desired by the user.
I'm not planning any changes along these lines for Ply-3.5, but will consider it in future releases later. Cheers, Dave On Apr 27, 2012, at 4:49 AM, David Cournapeau wrote: > > On Thu, Apr 26, 2012 at 7:27 PM, David Beazley <[email protected]> wrote: > I've been thinking about some cleanup to PLY lately and have a question. > Would anyone actually miss the table output in PLY (parsetab.py, lextab.py) > if it were removed entirely? Here's some context: > > The original version of PLY was developed on a 200 MHZ home computer about 12 > years ago. At that time, generation of the LALR tables was relatively > expensive so creating table files was a way of caching the result and reusing > it (much like Python uses .pyc files). Today, it's a bit different. For > instance, making the LALR tables for the ANSI C grammar (over 200 rules and > nearly 350 states) on a modern machine only takes around a half a second. > Thus, I'm honestly wondering if I could just ditch all of that table > reading/writing code and not worry about it. > > Does anyone have any particular thoughts about this? > > I use ply to parse the package declaration in my packaging tool bento, and > the related command line tools would be significantly slower without the ply > caching. > > OTOH, the current caching solution is a bit difficult to use in those > situation: I think having a pickable object, and extracting the caching > policy away from the main code would cover most usecases in that context. > > David -- You received this message because you are subscribed to the Google Groups "ply-hack" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/ply-hack?hl=en.
