Location of bytecode files (pyc)

[Skip Montanaro]

Bengt,

Thanks for your feedback...

    MvL> http://www.python.org/peps/pep-0304.html

    MvL> Comments on the PEP are encouraged: ...

    Bengt> Personally, I am a minimalist when it comes to environment
    Bengt> variables.  IMO that name space has the same problems as any
    Bengt> global namespace, and since a single default set of user's
    Bengt> environment variables tends to presented to most programs s/he
    Bengt> runs from a command window, the name space usage tends towards a
    Bengt> hodgepodge and/or wrapping apps in setup scripts (which can work
    Bengt> fine, but I still don't like it as a standard way to go).

You can set sys.bytecodebase explicitly, though you might have trouble
setting it early enough to push all your .pyc files where you want.  Note
that the patch associated with PEP 304 is written in C (import.c and
sysmodule.c are affected).

    Bengt> Provision for admin/root level config data separate from user
    Bengt> preference and session state type config data should be made as
    Bengt> necessary and desirable, but secondary/user config data search
    Bengt> should be controllable by the primary/root/admin config data
    Bengt> (which e.g. could say to ignore or use
    Bengt> user-controlled/attempted-control environment variables etc.).

Do you want Python to locate and load a config file at startup?  By the time
a config file parser is loaded and sys.bytecodebase set, lots of .pycs may
well have already been generated in the wrong place.  This shouldn't happen
with the patch I created.

    Bengt> This would seem to imply a standard place to look for root/admin
    Bengt> level config data, not directed by env variable. E.g., a
    Bengt> read-only file in the same directory as the python interpreter
    Bengt> executable, with, say, .conf or .cfg appended to the name. *That*
    Bengt> file can then specify how/whether to look for user config stuff
    Bengt> etc., or specify password access to some features, etc. etc., if
    Bengt> we wind up doing restricted exec stuff.

Like I said, lots of other stuff will likely have been imported by the time
you realize your .pyc files belong "over there" instead of where they're
being written, or were you volunteering to write a C version of ConfigParser
which is statically linked into the interpreter? ;-)

Skip