[Tutor] when is "pythondontwritebytecode" useful?

[Ben Finney]

Albert-Jan Roskam <fomcl at yahoo.com> writes:

> I know what it does
> (http://docs.python.org/2/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE),
> i.e. no pyc or pyo fiules are written, but WHY is that sometimes a
> good thing?

There are numerous reasons why one might not want files to suddenly be
written when a source file gets compiled.

> The only useful scenario I can think of is when you don't have write
> rights to create pyc files but you want to use a package anyway.

Another reason: The file is named such that adding the letter “c” at the
end is unhelpful.

When writing a program to be invoked by a command name, on Unix the
convention is to name the program file with the name of the command. So
the command “foo” is implemented in a file named ‘foo’, no suffix.

This program file needs unit tests, and the test runner will import that
file. At which point Python will compile it, and normally create a
bytecode file. The bytecode file will be named by appending “c” to the
name of the source file, resulting in the filename ‘fooc’.

That filename makes no sense, so I want to disable the writing of that
bytecode file when that source file is imported.


That is just one example, of the more general case that one doesn't want
a file arbitrarily appearing in a directory with properties partially
outside one's control. Can you think of others?

-- 
 \     “Buy not what you want, but what you need; what you do not need |
  `\             is expensive at a penny.” —Cato, 234–149 BCE, Relique |
_o__)                                                                  |
Ben Finney