[Python-Dev] Re: Proto-PEP regarding writing bytecode files

Paul F Dubois paul@pfdubois.com
Thu, 23 Jan 2003 09:08:24 -0800


This proposal has a kind of system-oriented view: there is one Python, =
and
the issue is whether or not to make bytecode files, and if so where to =
put
them. This view does not match reality very well.

>From the point of view of someone distributing a Python-based =
application,
one of the hardest things to control is the user environment, and yet
control of those environment settings might be an absolute requirement. =
For
example, a parallel application might need to suppress byte-code writing
when it would not need to be repressed for other purposes or other =
codes.
This application might have its own Python and it would be required that
that Python load modules only from itself, not from some random bytecode
directory that got added to my path because of an environment variable =
that
my sysadmin put in the central startup files unbeknownst to me.

I realize that for any objection I raise here there is a solution. For
example, make my "code" a shell that sets the environment before =
executing
the real code. But that is annoying when developers have to debug the =
thing.
I can set the environment variable from the application too but that =
raises
the issue of whether or not I have done this "in time" for it to be
effective or whether some other part of Python has already used the =
setting
(like changing the path, for example) before I got my chance.

The patch as posted suited me because I could just set the C flag or =
argv
entry from my own main code before I initialized Python; or I could set =
the
command line flag when executing with a shell script or as an alias. =20

I'm unclear about how this works if I have one environment variable but =
am
running different installations of Python. Couldn't I end up with a pyc
newer than any of its diverse sources and thus used even though it
corresponds to just one of them? It is useless to suppose that I am
"careful" and always remember what the PYCROOT ought to be. First of =
all,
I'm not careful, but even if I were I might be running Python via some =
other
application and not even realize it. It all starts to sound like DLLs.
Bottom line: I find any messing with my path to be suicidal.