799

From what I understand, a cache is an encrypted file of similar files.

What do we do with the __pycache__ folder? Is it what we give to people instead of our source code? Is it just my input data? This folder keeps getting created, what it is for?

Guillem Cucurull
  • 1,581
  • 1
  • 19
  • 28
user2063042
  • 8,037
  • 3
  • 12
  • 6
  • 35
    "Is it what we give people instead of our source code?" - No, you give them the source code in a nice installable package so it's easy to use. – Lennart Regebro Jun 01 '13 at 12:49
  • 107
    Nobody mentioned yet, but your definition of cache is bizarre. Cache is quite simply a [component that stores data so future requests for that data can be served faster](https://en.wikipedia.org/wiki/Cache_(computing)). – Ricardo Cruz Jul 22 '16 at 19:02
  • 5
    See: https://www.python.org/dev/peps/pep-3147/ – Mr_and_Mrs_D Apr 13 '17 at 18:47
  • 4
    Since `Python 3.8` you can use an environment variable to **change the location** for the annoying cache directories: https://stackoverflow.com/a/57414308/1612318 – Rotareti Aug 08 '19 at 14:02
  • 2
    A cache is something that keeps a copy of stuff in case you need it again, to save you having to go back to the original to get it. It's designed to be faster than going to the original place. It might be faster because it doesn't have to pre-process or compile the information. Or it might be faster storage, e.g. a disk cache in RAM or a web cache on a local disk. It's not by its nature encrypted (although it could sometimes be), and it's not always a "file of similar files" - it can be a file, a load of files, a block of RAM etc. – rjmunro Feb 04 '20 at 17:39

10 Answers10

674

When you run a program in python, the interpreter compiles it to bytecode first (this is an oversimplification) and stores it in the __pycache__ folder. If you look in there you will find a bunch of files sharing the names of the .py files in your project's folder, only their extensions will be either .pyc or .pyo. These are bytecode-compiled and optimized bytecode-compiled versions of your program's files, respectively.

As a programmer, you can largely just ignore it... All it does is make your program start a little faster. When your scripts change, they will be recompiled, and if you delete the files or the whole folder and run your program again, they will reappear (unless you specifically suppress that behavior).

When you're sending your code to other people, the common practice is to delete that folder, but it doesn't really matter whether you do or don't. When you're using version control (git), this folder is typically listed in the ignore file (.gitignore) and thus not included.

If you are using cpython (which is the most common, as it's the reference implementation) and you don't want that folder, then you can suppress it by starting the interpreter with the -B flag, for example

python -B foo.py

Another option, as noted by tcaswell, is to set the environment variable PYTHONDONTWRITEBYTECODE to any value (according to python's man page, any "non-empty string").

Ekevoo
  • 2,514
  • 1
  • 21
  • 31
scott_fakename
  • 7,659
  • 2
  • 12
  • 20
  • 58
    You can also add the environment variable `PYTHONDONTWRITEBYTECODE=` to suppress it permanently. – Mark Tolonen Jun 01 '13 at 15:29
  • 12
    Just to clarify, this is for Python 3 only, correct? – Joe J Feb 24 '14 at 22:39
  • 11
    @JoeJ yes, I think that's true. `python2` puts the compiled files in the same directory as the originals, if I'm not mistaken. – scott_fakename Feb 25 '14 at 01:20
  • 34
    One IMPORTANT caveat is that the cached .pyc file will be used instead of the .py file if the .py file is missing. In practice, this only happens if you delete (or rename) modules, so it's not a common occurance, but if some stuff keeps up being "there", after scratching your head, running find . -name \*.pyc | xargs rm o n your source is probably a good first reaction. – yacc143 Feb 28 '14 at 10:38
  • 39
    `find . -name '*.pyc' -delete` Yes, find has a flag for deleting the found files, so you don't have to use any xargs shananigans – vlad-ardelean Oct 07 '14 at 18:58
  • 2
    @JoeJ To be precise, it was introduced as part of Python 3.2. – spkersten Jun 02 '15 at 18:09
  • 2
    @yacc143: This only happens if the .pyc file is the directory where the .py file would be – that is, where Python 2 put them. Python 3 puts them in `__pycache__`, which is not used if the .py file isn't there. – Petr Viktorin Jul 12 '15 at 13:29
  • 3
    But you can still use a .pyc *instead* of a .py if you need that: just copy it out of `__pycache__`. – Petr Viktorin Jul 12 '15 at 13:29
  • I've seen this cache appear with Python2.7 when using `py.test` - I believe it uses it to implement its `assert` behaviour. – davidA Apr 06 '17 at 22:05
  • 2
    Is it okay to move these folders to another location? I'm trying to clean up my username directory. – Moondra Oct 15 '17 at 04:13
  • How does Python know when your source file is changed? Is it just due to mtime or ctime? Also what happens if you run a Python app inside a container with readonly root filesystem? Or what if you run a Python application but you don't have the permissions to write to the directory, but you do have read and execute permissions. – CMCDragonkai Sep 18 '18 at 05:08
  • could `` be 1 or "1" (as string)? – alper Aug 19 '20 at 01:29
210

__pycache__ is a folder containing Python 3 bytecode compiled and ready to be executed.

I don't recommend routinely laboriously deleting these files or suppressing creation during development as it wastes your time. Just have a recursive command ready (see below) to clean up when needed as bytecode can become stale in edge cases (see comments).

Python programmers usually ignore bytecode. Indeed __pycache__ and *.pyc are common lines to see in .gitignore files. Bytecode is not meant for distribution and can be disassembled using dis module.


If you are using OS X you can easily hide all of these folders in your project by running following command from the root folder of your project.

find . -name '__pycache__' -exec chflags hidden {} \;

Replace __pycache__ with *.pyc for Python 2.

This sets a flag on all those directories (.pyc files) telling Finder/Textmate 2 to exclude them from listings. Importantly the bytecode is there, it's just hidden.

Rerun the command if you create new modules and wish to hide new bytecode or if you delete the hidden bytecode files.


On Windows the equivalent command might be (not tested, batch script welcome):

dir * /s/b | findstr __pycache__ | attrib +h +s +r

Which is same as going through the project hiding folders using right-click > hide...


Running unit tests is one scenario (more in comments) where deleting the *.pyc files and __pycache__ folders is indeed useful. I use the following lines in my ~/.bash_profile and just run cl to clean up when needed.

alias cpy='find . -name "__pycache__" -delete'
alias cpc='find . -name "*.pyc"       -delete'
...
alias cl='cpy && cpc && ...'

and more lately

# pip install pyclean
pyclean .
fmalina
  • 5,443
  • 4
  • 30
  • 45
  • Wouldn't this be undone every time you run the code? – Holloway Feb 06 '15 at 12:39
  • No, I just tested on Python 2 and 3 to double check. It will only be undone if you delete the hidden files. Than you need to run it again. – fmalina Feb 06 '15 at 14:09
  • What would happen if theres no permission to create those files in the directory where .py file is launched? For example linux /usr/share/... – DoTheEvo Jun 26 '15 at 10:58
  • 2
    @DoTheEvo: it simply doesn't get created, so there's no speedup next time the module is loaded. No error is raised. – Petr Viktorin Jul 12 '15 at 13:31
  • 11
    This isn't a good answer. The asker wants to know what these files are for. This answer says "don't worry about it" and then makes them disappear. – interestinglythere Oct 06 '15 at 19:25
  • 50
    ***Absolutely** bother deleting these*: it is not pointless. Python will happily not detect file changes and run off a cache file in many circumstances, driving you up the wall with "why the f does it still not work, I changed the code, why is it still failing on nonexistent calls" nonsense. Especially in test frameworks, pycache-by-default is the worst. – Mike 'Pomax' Kamermans May 11 '17 at 23:12
  • What circumstances? Over the past 10 years, everytime I suspected bytecode to be the problem it was actually somewhere else. – fmalina May 12 '17 at 17:25
  • it's not totally pointless. Syncing files between computers will cause unit tests to fail – endolith Jul 15 '17 at 12:50
  • 2
    I would disagree with this advice to "not bother deleting these files" - have seen this recommended many times, most recently by [Kenneth Reitz's "How To Python"](http://howtopython.org/en/latest/the-interpreter/#bytecode-trick) ("the bytecode trick") – Louis Maddox Jan 20 '18 at 22:47
  • My reason for deleting them is that I'm using CPack and NSIS on Windows to package up some python in an installer. Without these I don't hit the ludicrous 260 char limit for a filepath, and all is well. With these ... (aaaargh!!!) – Neil Gatenby Feb 14 '18 at 09:44
  • @linebreak Tried your `alias` trick to clean up `__pycache__` files and got this error: `find: cannot delete './__pychace__': Directory not empty` – devjoco Apr 14 '20 at 05:40
  • This answer by @SalientGreen provided a much better way to clean it up: https://stackoverflow.com/a/28991449/7737266 – devjoco Apr 14 '20 at 05:46
  • The link in my answer above has broken, the site seems to have been replaced by a spam site. Here's the archived page written by Ken Reitz: https://web.archive.org/web/20190109100200/https://www.howtopython.org/en/latest/the-interpreter/#bytecode-trick The source repo has moved to an archive: https://github.com/kennethreitz-archive/howtopython.org – Louis Maddox Jul 08 '20 at 11:52
53

A __pycache__ folder is created when you use the line:

import file_name

or try to get information from another file you have created. This makes it a little faster when running your program the second time to open the other file.

funnydman
  • 2,957
  • 3
  • 13
  • 29
Aliaksandr S.
  • 764
  • 7
  • 17
34

Updated answer from 3.7+ docs:

To speed up loading modules, Python caches the compiled version of each module in the __pycache__ directory under the name module.version.pyc, where the version encodes the format of the compiled file; it generally contains the Python version number. For example, in CPython release 3.3 the compiled version of spam.py would be cached as __pycache__/spam.cpython-33.pyc. This naming convention allows compiled modules from different releases and different versions of Python to coexist.

Source: https://docs.python.org/3/tutorial/modules.html#compiled-python-files

That is, this directory is generated by Python and exists to make your programs run faster. It shouldn't be committed to source control, and should coexist in peace with your local source code.


__pycache__ is a directory that contains bytecode cache files that are automatically generated by python, namely compiled python, or .pyc, files. You might be wondering why Python, an "interpreted" language, has any compiled files at all. This SO question addresses that (and it's definitely worth reading this answer).

The python docs go into more depth about exactly how it works and why it exists:

  • It was added in python 3.2 because the existing system of maintaining .pyc files in the same directory caused various problems, such as when a program was run with Python interpreters of different versions. For the full feature spec, see PEP 3174.
FluxLemur
  • 1,329
  • 13
  • 18
7

from the official python tutorial Modules

To speed up loading modules, Python caches the compiled version of each module in the __pycache__ directory under the name module.version.pyc, where the version encodes the format of the compiled file; it generally contains the Python version number. For example, in CPython release 3.6 the compiled version of spam.py would be cached as __pycache__/spam.cpython-36.pyc.

from Python doc Programming FAQs

When a module is imported for the first time (or when the source file has changed since the current compiled file was created) a .pyc file containing the compiled code should be created in a __pycache__ subdirectory of the directory containing the .py file. The .pyc file will have a filename that starts with the same name as the .py file, and ends with .pyc, with a middle component that depends on the particular python binary that created it.

Yossarian42
  • 1,584
  • 12
  • 12
5

Execution of a python script would cause the byte code to be generated in memory and kept until the program is shutdown. In case a module is imported, for faster reusability, Python would create a cache .pyc (PYC is 'Python' 'Compiled') file where the byte code of the module being imported is cached. Idea is to speed up loading of python modules by avoiding re-compilation ( compile once, run multiple times policy ) when they are re-imported.

The name of the file is the same as the module name. The part after the initial dot indicates Python implementation that created the cache (could be CPython) followed by its version number.

TechFree
  • 1,531
  • 1
  • 7
  • 11
5

When you import a module,

import file_name

Python stores the compiled bytecode in __pycache__ directory so that future imports can use it directly, rather than having to parse and compile the source again.

It does not do that for merely running a script, only when a file is imported.

(Previous versions used to store the cached bytecode as .pyc files that littered up the same directory as the .py files, but starting in Python 3 they were moved to a subdirectory to make things tidier.)

PYTHONDONTWRITEBYTECODE ---> If this is set to a non-empty string, Python won’t try to write .pyc files on the import of source modules. This is equivalent to specifying the -B option.

Ehsan Barkhordar
  • 2,250
  • 17
  • 24
4

The python interpreter compiles the *.py script file and saves the results of the compilation to the __pycache__ directory.

When the project is executed again, if the interpreter identifies that the *.py script has not been modified, it skips the compile step and runs the previously generated *.pyc file stored in the __pycache__ folder.

When the project is complex, you can make the preparation time before the project is run shorter. If the program is too small, you can ignore that by using python -B abc.py with the B option.

Marcus Thornton
  • 5,043
  • 5
  • 41
  • 45
4

Python Version 2.x will have .pyc when interpreter compiles the code.

Python Version 3.x will have __pycache__ when interpreter compiles the code.

alok@alok:~$ ls
module.py  module.pyc  __pycache__  test.py
alok@alok:~$
Alok Tiwari
  • 188
  • 7
2

In 3.2 and later, Python saves .pyc compiled byte code files in a sub-directory named __pycache__ located in the directory where your source files reside with filenames that identify the Python version that created them (e.g. script.cpython-33.pyc)

notpeter
  • 744
  • 8
  • 14
  • How can I avoid the creation of "__pycache__" folder and all .pyc should be named same as .py file? – Ashwani Dec 16 '19 at 08:23