Just saw this. I don't mind the idea of using tempfiles at all, but I noticed this discussion seems to be very *nix focused. Please consider using tempfile.gettempdir() instead of literally /tmp, for those of us stuck in Windoze land part-time.
David Bliss 1-616-284-1273 On Mon, Jul 8, 2013 at 8:11 AM, John Szakmeister <[email protected]>wrote: > On Mon, Jul 8, 2013 at 7:58 AM, David Beazley <[email protected]> wrote: > [snip] > >> Can you provide more information about how this would work? Say user1 > >> has a tool installed, built on PLY, that's using version 1.0 of the > >> grammar, and user2 has the same tool installed, but it's using version > >> 2.0 of the grammar. Do they both get written to the same file when > >> the parse tables are generated? > > > > I was thinking about making the name of the written file incorporate > some kind of unique signature to keep it separate from other users of PLY. > For example, it could be based on the absolute file parse of the code that > invokes PLY or maybe the parsetab signature that gets computed. So the > parsing data from different grammars and users of PLY would be written to > separate files. > > That makes sense. > > >> Would the developer using PLY provide > >> something that's used to influence how the directory or file gets > >> named? > > > > No, although an option to specify the location of the temporary > directory would be provided. > > > >> Is there an issue with someone monkeying with parse tables to > >> make something happen that shouldn't happen--a security problem of > >> sorts? > > > > Hard to say. The new approach wouldn't be using 'import' to load > parsing data however. As such, it could be encoded in a different format > such as JSON. Maybe it's safer than what's done now. > > I think there are probable a few more things to think about along this > line. The resultant file would be created with the running user's > permissions. So, without some care, one user could create the file, > and another might not be able to read it due to permissions issues. > Maybe the user's umask isn't set up to allow everyone read access, for > instance. I could definitely see some headaches in this arena. > > >> Could we still package the parsetab.py file with our RPM > >> install, if we wanted to avoid the overhead? > > > > There wouldn't be a proper parsetab.py file anymore. I suppose the > generated output file could be distributed as long as you were willing to > tell PLY the directory where it was located. > > I guess if PLY doesn't attempt to open the file with write permissions > (if it's happy with the signature), then that could work. > > -John > > -- > You received this message because you are subscribed to the Google Groups > "ply-hack" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ply-hack/CAEBDL5XrxfRzMsiAOd%2Bc39GbPKrToD6utwREuMKDf%3D%3Dq6-RCOA%40mail.gmail.com > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "ply-hack" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ply-hack/CAN%3DgvHqu-2KN3Mahzp6y%3D5KJHvaq4rny%3DSnphmeR28vmJHviCQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
