Thomas Heller wrote: > Although I was not interested originally, I think that's > a use case I also have. Optional config files, which > should not be compiled to .pyc or .pyo. Only removing > the .py file doesn't have the expected effect > if a .pyc and/or .pyo if is left.
I also think that if nobody has the same use-case as envisioned by the original PEP, we should probably step back and rethink how it should be implemented. The original PEP envisioned the installation of third-party .py file libraries without their corresponding .pyc files into directories for which the eventual script user had no write-access. As more people become coginzant of the correct way to install Python libraries, I think this use-case fades in importance. The key distinction between this older use-case and the currently envisioned use-case is that the former assumes third-party code, and the latter assumes that the control over .pyc generation is desired by the _author_ of some python code, rather than merely the _installer_ of some python code. In this latter case, environment variables are not strictly necessary, because the top-level script could do whatever it needs to control .pyc generation, from inside Python itself. > AFAIK, it is not possible to define empty env vars on Windows. You make a good point about null environment variables. I think the original PEP was fairly *nix-centric, both in that aspect, and in the aspect of requiring the value of bytecodebase to be the "root" of the file system. This might not have the desired results in all cases on Windows. Regards, Pat -- http://mail.python.org/mailman/listinfo/python-list
