2

This answer tells me that a .pyc file gets created when a .py file is run, which I understand saves loading time when re-run. Which makes me wonder what the point of the .py file is after the .pyc is created.

When backing up my code, or sharing it, I don't want to include redundant or extraneous files. Which filetype should I focus on?

Side question: I have one script that calls another. After running them, the called script got a .pyc file written, but the master script that does the calling did not. Why would that be?

Community
  • 1
  • 1
joechoj
  • 1,339
  • 10
  • 12
  • 2
    If you ever wish to edit or debug your code, you need the `.py`. See http://stackoverflow.com/questions/3878479/why-are-main-runnable-python-scripts-not-compiled-to-pyc-files-like-modules for your second question. – AChampion Nov 13 '16 at 01:00
  • So `.py` is the 'master' file, essentially, and `.pyc` can always be regenerated from it? – joechoj Nov 13 '16 at 01:09
  • `.pyc` is the compiled file (from `.py` which contains the source code), it contains the byte code – Khaled Nov 13 '16 at 01:12
  • Some of my thought. Backing up code should use .py, sharing could be both, use .pyc if you you want to add some difficulty for others to access the source code, though there is still way to get back .py from .pyc. – Skycc Nov 13 '16 at 01:13
  • the .py file contains the source code that could be useful to add updates. – Raul R. Nov 13 '16 at 01:14
  • ``.pyc`` files are specific to the version of Python that created them. Anyone with a different Python version would not be able to use them, even if the original ``.py`` is compatible with that version. – jasonharper Nov 13 '16 at 02:49

2 Answers2

5

Python .pyc files are generated when a module is imported, not when a top level script is run. I'm not sure what you mean by calling, but if you ran your master script from the command line and it imported the other script, then only the imported one gets a .pyc.

As for distributing .pyc files, they are minor version sensitive. If you bundle your own python or distribute multiple python-version sensitive files, then maybe. But best practice is to distribute the .py files.

Python's script and module rules seem a bit odd until you consider its installation model. A common installation model is that executables are installed somewhere on the system's PATH and shared libraries are installed somewhere in a library path.

Python's setup.py does the same thing. Top level scripts go on the PATH but modules and packages go in an library path. For instance on my system, pdb3 (a top level script) is at /usr/bin/pdb3 and os (an imported module) is at /usr/lib/python3.4/os.py. Suppose python compiled pdb3 to pdb3.pyc. Well, I'd still call pdb3 and the .pyc is useless. So why clutter the path?

Its common for installs to run as root or administrator so you have write access on those paths. But you wouldn't have write access to them later as a regular user. You can have setup.py generate .pyc files during install. You get the right .pyc files for whatever python you happen to have, and since you are running as root/admin during install you still have acess to the directories. Trying to build .pyc files later is a problem because a regular user doesn't have access to the directories.

So, best practice is to distribute .py files and have setup.py build the .pyc during install.

tdelaney
  • 73,364
  • 6
  • 83
  • 116
  • By 'call' I mean it opens and runs another script. Am I not using the right term? Specifically, in my master script I have a couple lines that import an external module that's housed in another `.py` file, and then run the `main()` function of that module. – joechoj Nov 13 '16 at 01:19
  • @joechoj - Its ambiguous. You can `import` a module and call its functions (you get a .pyc) or you can execute a script as a child process using something like `subprocess` (no .pyc) but you can't call a script. When you say "it runs another script" that implies that its being executed as an independent subprocess but I'm not sure that's what you mean here. Long story short, if you used the `import` keyword, you imported it and you get a .pyc. – tdelaney Nov 13 '16 at 01:26
  • @joechoj - I am sounding pedantic here and normally looser language is fine. In this case, where we are figuring out when .pyc files get created, it does make a difference. – tdelaney Nov 13 '16 at 01:43
3

If you simply want to run your Python script, all you really need is .pyc which is the bytecode generated from your source code. See here for details on running a .pyc file. I will warn that some of the detials are bit twisty.

However I recommend including your source code and leaving out your .pyc files as they are generated automatically by the Python Interpreter. Besides, if you, or another person would want to revise/revisit your source code at a later point, you would need the .py files. Furthermore, it is usually best practice to just include your source code.

Community
  • 1
  • 1
Christian Dean
  • 22,138
  • 7
  • 54
  • 87