9

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.

Jon Clements
  • 138,671
  • 33
  • 247
  • 280
sorin
  • 161,544
  • 178
  • 535
  • 806

4 Answers4

20

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:

  • Forget the export. You can echo $PYTHONDONTWRITEBYTECODE you want, and it's clearly set, and yet python isn't seeing it…
  • Remember the 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.)
  • Remember to export, but export the wrong variable (usually by careless misuse of history in an attempt to save a few keystrokes).
  • Typo. No matter how many times you stare at PYTHONDOTWRITEBYTECODE it looks fine…
  • Do some setup in the Terminal, switch to another window, come back to the wrong Terminal window, and run python.
  • Edit ~/.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.
  • Launch one Python script from another using 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.
  • Launch Python from C with 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.

abarnert
  • 354,177
  • 51
  • 601
  • 671
6

You can avoid the creation of both .pyc and .pyo files with: python -B script.py

dave mankoff
  • 17,379
  • 7
  • 50
  • 64
  • I don't want to change the command line that calls python, that doesn't scale at all. I think that there is a bug that it does not care about the ENV variable. – sorin Dec 14 '12 at 16:57
  • How are you executing Python? If you're executing through some sort of bash script or other method, it could be that the environment is being reset it some way. – dave mankoff Dec 14 '12 at 20:44
5

Setting the environment as described by abarnert is really the right way to do this, but if for some reason that's not possible in your setup you can set it at runtime in the code.

Just add the following to the top of your script:

import sys
sys.dont_write_bytecode = True

This will keep python from generating any bytecode after that point. 

$ cat > foo.py
#sample module
FOO="BAR"

$ python
>>> import sys
>>> sys.dont_write_bytecode = True
>>> import foo
>>> foo.FOO
'BAR'
>>> ^D

$ ls *.pyc
ls: *.pyc: No such file or directory
cnelson
  • 1,355
  • 11
  • 14
1

I would suggest this at the top of your python script:

#!/usr/bin/env python -B

Or, use the sys.dont_write_bytecode method.

See also: How to avoid .pyc files? which suggests a few other solutions, including one method that works in pre-2.6 python.

Community
  • 1
  • 1
Alex I
  • 19,689
  • 9
  • 86
  • 158