On Sun, Jan 31, 2010 at 6:04 AM, Jeffrey Yasskin <jyass...@gmail.com> wrote: > 2. Vitor's suggestion to make 1 "pyr" directory per directory and > stick all the .pyc's there would solve the "pyc clutter" problem. Any > reason not to do that? Trying to make it 1-pyr-per-directory-hierarchy > as Ben suggested seems unworkable. The one problem with this would > seem to be filename length limits; do we care about those anymore?
I'd view this type of cache information in a similar way to version control metadata. Taking that analogy one directory named ".pyr" per directory seems to be an obvious choice mirroring CVS and Subversion. Most tools and developers have learned to deal with ignoring "CVS" and ".svn" directories. More modern version control systems don't clutter every directory with its metadata anymore, but put use a single ".git" or ".hg" directory in the root of the "repository". But Python code doesn't have such a clear notion of a "root" for the code. Depending on whether the code is part of a distribution, a package, a module or a stand-alone script it's unclear where the cache should live. In addition it seems to be more common to symlink code directories from various places into single locations, making the job of finding a potential root more complicated. I'd be a big +1 to using a single ".pyr" directory per source directory. Hanno _______________________________________________ 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
