PEP 304 - Controlling generation of bytecode files

[Ian Bicking]

On Wed, 2003-01-29 at 13:10, Skip Montanaro wrote:
>     Ian> The PEP should be unambiguous about the search path.  In
>     Ian> particular, say /foo shows up in the search path before /bar, and I
>     Ian> create a file /foo/file.py, use it and decide it should go in
>     Ian> /bar/file.py.  I likely won't delete /pycfiles/foo/file.pyc, but it
>     Ian> would be *horrible* if that outdated file got imported.  I can
>     Ian> easily imagine tearing my hair out for some time if that happened
>     Ian> and I didn't notice it.
> 
> That outdated .pyc file will get imported.  It's your responsibility to
> manage your directory tree properly.  If you think this is a bug, please
> file a report on SF (though I don't whoever responds will consider it a
> bug).

Well, it's somewhat of a bug with the current behavior (IMHO), or at
least error-prone, but the bug could be *much* worse if you have pyc
files separate from the py files.

In the current situation if you move a file you should also notice the
presence of the .pyc file.  At least, I do.  But if you are keeping your
.pyc files separate from your py files then you are more likely to miss
the stale .pyc file.  

I think the more appropriate behavior would be, at least if bytecodebase
was being used, that the .pyc files would only be loaded from that
location if the corresponding .py file existed.  If people want to use
.pyc files without .py files, then they should put those .pyc files
somewhere in sys.path, not in an implicit search path. (I don't really
like .pyc files w/o corresponding .py files anyway, but if you want to
use them they should be directly in the path).

I'm not sure if the PEP addressed that either -- if you have a search
path with /foo, and a bytecodebase of /pyc, and there's no /foo/bar.py
or /pyc/foo/bar.pyc (or /pyc/bar.pyc? either way I guess), then if
there's a /foo/bar.pyc will it be found?  

  Ian