It seems that on OS X 10.8 (with Python 2.7) the .pyc
files are created even if you setup the environment variable PYTHONDONTWRITEBYTECODE=1
How can I prevent this from happening, or how can I convince Python not to create this files in the same location as the source files.
Python can now be prevented from writing . pyc or . pyo files by supplying the -B switch to the Python interpreter, or by setting the PYTHONDONTWRITEBYTECODE environment variable before running the interpreter. This setting is available to Python programs as the sys.
. pyc files are created by the Python interpreter when a . py file is imported. They contain the "compiled bytecode" of the imported module/program so that the "translation" from source code to bytecode (which only needs to be done once) can be skipped on subsequent imports if the .
. py files contain the source code of a program. Whereas, . pyc file contains the bytecode of your program.
You do need an executable to actually load the files into the VM. Fortunately it doesn't need to be very complex. If you want a direct answer, then "No, the end user will not need to have Python installed. But just the DLL will not be enough.".
I just tested this, and it works fine on 10.8.2 with the Apple-installed Python 2.7.
$ echo -e 'import bar\n' > foo.py
$ echo -e 'pass\n' > bar.py
$ export PYTHONDONTWRITEBYTECODE=1
$ python foo.py
$ ls -l bar.py*
-rw-r--r-- 1 abarnert staff 6 Dec 14 17:25 bar.py
$ unset PYTHONDONTWRITEBYTECODE
$ python foo.py
$ ls -l bar.py*
-rw-r--r-- 1 abarnert staff 6 Dec 14 17:25 bar.py
-rw-r--r-- 1 abarnert staff 118 Dec 14 17:26 bar.pyc
You can replace python
with python2.7
, python2.6
, or python2.5
, and you'll get the same result.
And it also works with all of the Apple-installed Pythons from 10.5-10.7, and with all of the python.org, Enthought, MacPorts, and Homebrew Pythons I have on the various machines available to me, and the standard python packages on two different linux distros.
So if this is a bug, it's a very specific one, meaning you'll have to tell us exactly which Python (and how you installed it, if not stock), and which OS X 10.8.
It's far more likely that PYTHONDONTWRITEBYTECODE
just isn't in python's environment. As Mark Ransom suggested, you can verify this by adding:
import os
print 'PYTHONDONTWRITEBYTECODE is', os.environ.get('PYTHONDONTWRITEBYTECODE', None)
If it says None
, this is the problem.
So, PYTHONDONTWRITEBYTECODE
is not in your environment. But you say it is in your calling environment. How is that possible? Well, if you're using bash
, the most likely reason is that you forgot to export
it. Out of all the stupid ways to do this, that's the one I've done the most. But here are some stupid things I've done:
export
. You can echo $PYTHONDONTWRITEBYTECODE
you want, and it's clearly set, and yet python
isn't seeing it… export
, but forget to set it. bash
lets you export PYTHONDONTWRITEBYTECODE
even if it's not defined to anything.export $PYTHONDONTWRITEBYTECODE
. (You can avoid this one by setting it to something that's not a valid identifier, like 1
.)export
, but export
the wrong variable (usually by careless misuse of history in an attempt to save a few keystrokes).PYTHONDOTWRITEBYTECODE
it looks fine…python
.~/.bash_profile
, and instead of re-loading it or starting a new shell, figure "I'll just do the same thing directly", and make some silly typo, and then spend half an hour looking at my .bash_profile
to see what I got wrong before thinking about looking at my shell history.subprocess
/os.exec*
/whatever, going out of my way to ask for a clean environment, then wondering why my environment variable isn't showing up.execl
instead of execle
, so your intended envp
argument has no effect. (On some platforms, this can segfault, but not x86/x64 OS X.)At any rate, if you tried this manually in the terminal, try again.
If you're doing this in your .bash_profile
, a launcher shell script, a launcher Python script, or whatever, show us the relevant code and someone will immediately find your stupid error. If they laugh at you, tell them to read my answer so they can laugh at me instead.
PS, Note that I did export PYTHONDONTWRITEBYTECODE=1
instead of separate PYTHONDONTWRITEBYTECODE=1
and export PYTHONDONTWRITEBYTECODE
lines in my test. I always do this, except in shell scripts that have to be portable, because it's easier to debug the blatant error you get when trying this on an old-school shell that doesn't have the direct export syntax than to debug the problems caused by all the stupid mistakes I cataloged above.
You can avoid the creation of both .pyc and .pyo files with: python -B script.py
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With