Location of bytecode files (pyc)

Rim rimbalaya at yahoo.com
Wed Sep 3 20:28:57 CEST 2003

> If you're on Windows say:
> del /S *.pyc
> to remove all .pyc's from cwd and below.

Yes, and in linux 'find . -name "*.pyc" -exec rm -rf {} \;', but that
is not the point. I did not ask about how to remove pyc files, I asked
about placing them far from source code, in another directory, so they
would not be seen by the backup software.

The backup software runs continuously day, night, weekends, all the
time. Sweeping the pyc's under the carpet each time the backup is
about to be saving my files is impossible. That is why we store all
gcc object files and executables we produce on non-backed up
filesystems by prefixing target filenames in makefiles with a variable

We save hundreds of Gigs of disk space this way.

PEP 304 appears to give me what I need.

As Bengt suggest, adding yet another env var to control the operation
of an application polutes the name space for all applications, but
each app only needs to look at the variables it is concerned with.
PYTHONBYTECODEBASE is a cleaner approach that has less overhead than a
configuration file. Also, env variables are directly usable in
makefiles, which makes them very attractive and easy to use for
managing where compiler output goes.

Say you work on multiple projects simultaneously with different
locations for the byte code. The configuration files approach becomes
an administrative burden with conditionals based on the project name
in your config file.

The typical way we handle project specific configurations is through
environment variables that get set in the startup files. Depending on
a PROJECT environment variable, the PYTHONBYTECODEBASE can easily be
set to different directories without creating additional .cfg files.


More information about the Python-list mailing list