Hanno Schlichting wrote: >+1 for a single strategy that is used in all cases. The current >solution could be phased out across multiple releases, but in the end >there should be a single approach and no flag. Otherwise some code and >tools will only support one of the approaches, especially if this is >seen as something "only a minority of Linux distributions uses".
-1. As far as I can tell, this PEP proposes to solve a specific problem that Linux distributions have. As they have decent package managers, this PEP makes their maintainers' lives a lot easier. If implemented, I believe it would eventually be used by all of them, not just "a minority". For just about anyone else, I believe the current situation works perfectly fine, and should not be changed. Personally, I work mainly on Windows, and things I install are placed in the site-packages directory of the Python version I use. There is no need to place .pyc files in subdirectories there, as there will only ever be one. Programs I write myself are also rarely, if ever, run by multiple Python versions. They get run by the default Python on my system; if I change the default, the .pyc files get overwritten, which is exactly what I want, I no longer need the old ones. As to the single cache directory per directory versus per .py file issue: a subdirectory per .py file is easier to manipulate manually; listing the .py file and the subdirectory containing the compiled versions belonging to it makes it somewhat easier to prevent errors due to deleting the source but not the compiled version. However, as the use-case for this PEP seems to be to make life easier for Linux packagers, it seems that a single __pycache__ subdirectory (or whatever the name would be) is preferable: less filesystem clutter, and no risks of forgetting to delete .pyc files, as this is about system-managed Python source. Gertjan. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
