[destilled from http://bugs.debian.org/96111]

Currently python tries to write the .py[co] files even
in situations, where it will fail, like on read-only
mounted file systems.

In other situations I don't want python trying to write
the compiled files, i.e. having installed the modules
as root as part of a distribution, compiled them
correctly, there is no need to write them. Or compiling
.py files which are configuration files.

Is it reasonable to add an option to python
(--dont-write-compiled-files) to the interpreter, which
doesn't write them? This would not affect existing code
at all.

Logged In: YES 
user_id=33168

Guido, do you think this is a good idea?  If so, assign back
to me and I'll work up a patch.

Logged In: YES 
user_id=6380

I think it's a good idea, but please use a single upper case
letter for the option. Python doesn't support long options
and I'm not about to start doing so.

Logged In: YES 
user_id=21627

The patch looks good, but is surely incomplete: there should
be patches to the documentation, in particular to the man page.

It might be also desirable to parallel this option with an
environment variable, and/or to expose it writable through
the sys module.

With the environment variable, people could run Python
scripts that won't create .pyc files (as #! /usr/bin/env
python does not allow for further command line options).
With the API, certain applications could declare that they
never want to write .pyc files as they expect to run in
parallel with itself, and might cause .pyc conflicts.

Logged In: YES 
user_id=33168

You are correct about the patch being incomplete.  I still
have to do all the doc.

I hadn't thought about an env't variable or variable in sys.
 Both are certainly reasonable.  I will update the patch.

Logged In: YES 
user_id=357491

PEP 304 now handles this situation.

Logged In: YES 
user_id=33168

I think Skip now owns this because of his PEP. :-)

Logged In: YES 
user_id=44345

I have a c.l.py message buried in my python mailbox which raises some
Windows-related problems.  I have yet to figure that out, but they looked
somewhat difficult on first glance.  I'll try to dredge that up and attach
it to this id.

Turning in a feature request.

Took me awhile (nearly four years!) to find it, but I finally found the c.l.py message I referred to regarding Windows problems.  It's attached.

Skip

File Added: kew-msg

Is there likely to be any action on this. We can get issues with the
creation of .pyc files due to our build setup. We can get situations
where we run builds in parallel on 2 different architectures. Our build
is set up so that anything generated by compilers end up in individual
architecture specific directories, but we cannot do this with python. We
are also using clearmae, which has its own build avoidance features,
which get thoroughly confused by the generation of these files)

End result is one of
1) We get corrupt .pyc files
2) The build breaks
3) We rebuild things we don't need to.

We'd be very grateful for a way of suppressing the generation of .pyc
files completely.

Since the PEP is now withdrawn, I updated Neal's patch to the trunk and
added the env variable as well as the sys module value, including
documentation.

Should the read only option be considered for 2.6?

I'm okay with this feature, and the patch looks fine, except I don't
like the names used.  It's not really about "read-only-ness" of
bytecode, it's about whether we write certain files.  I'd suggest naming
the envvar PYTHONDONTWRITEBYTECODE, the C flag variable
Py_DontWriteByteCodeFlag, and the sys variable sys.dont_write_byte_code.
 With those changes I'm find with Georg checkin it in.

For some reason I don't love the use of "dont", with the missing 
apostrophe.  Just looks ugly to me.  But I don't know if "donot" is that 
much better.  And I don't think "PYTHONSKIPWRITINGBYTECODE" is much 
better.

In other words, I wish there was a better option, but I don't think any 
of my suggestions are really better.

"dont" is a pretty common contraction (see e.g. telnet.py).

Does the flag name -R still make sense with the new env var name?

What do you think about PYTHONOMITPYC, --omit-pyc and sys.omit_pyc_creation?

Attaching new diff, with -B flag name, PYTHONDONTWRITEBYTECODE, and
sys.dont_write_bytecode.

Looks good, please commit!

(Christian: the problem with using PYC in the envar name is that it is
ambiguous about what happens to PYO files...)

PS the patch still has a problem:

Python/pythonrun.c:177: error: ‘Py_ReadOnlyBytecodeFlag’ undeclared
(first use in this function)

Committed r59824.