Location of bytecode files (pyc)

[Bengt Richter]

On 03 Sep 2003 07:12:07 +0200, martin at v.loewis.de (Martin v. =?iso-8859-15?q?L=F6wis?=) wrote:

>rimbalaya at yahoo.com (Rim) writes:
>
>> How can I control the location of the bytecode files?
>
>You currently can't. See PEP 304, though, at
>
>http://www.python.org/peps/pep-0304.html
>
>Comments on the PEP are encouraged: If you won't comment now on
>whether the proposed change would solve your problem, it might be that
>you find something useless got implemented later.
>
Personally, I am a minimalist when it comes to environment variables.
IMO that name space has the same problems as any global namespace,
and since a single default set of user's environment variables tends to
presented to most programs s/he runs from a command window, the name space
usage tends towards a hodgepodge and/or wrapping apps in setup scripts (which
can work fine, but I still don't like it as a standard way to go).

IMO the os.environ name space should be treated like a root directory name space,
and not have application data per se in it (with reluctant exceptions where it is used wholesale
as in CGI). Rather, IMO, and only if necessary in the first place, it should be used to specify
location or search path info for config data, not *be* config data.

And a user-set environment variable should not be able to cause a bypass of root/admin-defined
config info where the distinction is necessary.

(The PYTHONBYTECODEBASE variable does refer to a directory, but now that makes two variables,
counting PYTHONPATH, and where will it end?)

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

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

A user config file overriding any other *user* config info could be specified by command line option,
e.g., -cfg myConfigFile.conf, and whether this or other command line options were allowed could be
(and should be able to be when control is necessary) specified in the root/admin config file.

... just my .02USD

Regards,
Bengt Richter