One other valid problem I've heard raised about git-based
deploys is that you can end up with cruft in your working
copy that sticks around like .pyc files where the
original .py file is deleted and there is the chance that
this file could still be imported even though the
original .py was deleted.
I'm shocked. If a py file is modified, the pyc is rebuilt. So we know it's poking at the original source file. Why not fail to import if the original source is missing?
Maybe this behavior is meant to support binary-only distribution of Python applications, but there really should be an option to override this behavior.
Edit: Did a bit more research and found this:
(1) http://docs.python.org/release/1.5.1p1/tut/node43.html
It is possible to have a file called "spam.pyc" without
a module "spam.py" in the same module. This can be used
to distribute a library of Python code in a form that is
moderately hard to reverse engineer.
Makes sense.
(2) http://docs.python.org/using/cmdline.html#cmdoption-B
If given, Python won’t try to write .pyc or .pyo files
on the import of source modules.
So you can mitigate that behavior by removing existing pyc files and using "-B".
Maybe this behavior is meant to support binary-only distribution of Python applications, but there really should be an option to override this behavior.
Edit: Did a bit more research and found this:
(1) http://docs.python.org/release/1.5.1p1/tut/node43.html
Makes sense.(2) http://docs.python.org/using/cmdline.html#cmdoption-B
So you can mitigate that behavior by removing existing pyc files and using "-B".