Ben Finney wrote:
> I don't think keeping the cache files in a mass of intertwingled extra
> subdirectories is the way to solve that problem. That speaks, rather, to
> the need for Python to be able to find the file on behalf of the user
> and blow it away on request, so the user doesn't need to go searching.
> Possible interface (with spelling of options chosen hastily)::
>     $ python    # Use cached byte code if available.
>     $ python --force-compile    # Unconditionally compile.
> If removing the byte code file, without running the module, is what's
> desired::
>     $ python --delete-cache     # Delete cached byte code.
>     $ rm $(python --show-cache-file  # Same as above.
> That should cover just about any common need for the user to know
> exactly which byte code file corresponds to a given source file. That,
> in turn, frees us to choose a less obtrusive location for the byte code
> files than mingled in with the source.

That's nice in theory, but tricky in practice given the intended
flexibility of the import system (i.e. we don't want to perpetrate new
import features that aren't part of the common importer interface, so
any such proposal would need to come complete with suggested extensions
to the PEP 302 importer protocol).

It's also the case that having to run Python to manage my own filesystem
would very annoying. If a dev has a broken .pyc that prevents the
affected Python build from even starting how are they meant to use the
nonfunctioning interpreter to find and delete the offending file? How is
someone meant to find and delete the .pyc files if they prefer to use a
graphical file manager over (or in conjunction with) the command line?

We can provide a utility script in the Python distribution to copy a
source tree without the Python cache directories easily enough, which
would be far simpler than providing the extra tools to cherry pick
compilation or deletion of individual cache files.


Nick Coghlan   |   |   Brisbane, Australia
Python-Dev mailing list

Reply via email to