On Sat, Feb 6, 2010 at 5:10 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: > Ben Finney wrote: >> Right; I don't see who would disagree with that. I don't see any >> conflict between “decouple compiled bytecode file locations from source >> file locations” versus “predictable location for the compiled bytecode >> files”. > > The more decoupled they are, the harder it is to manually find the > bytecode file. > > With the current .pyc scheme, .pyr folders or an SVN style Python cache > directory, finding the bytecode file is pretty easy, since the cached > file is either in the same directory as the source file or in a > subdirectory. > > With any form of shadow hierarchy though, it gets trickier because you > have to: > 1. Find the root of the shadow hierarchy > 2. Navigate within the shadow hierarchy down to the point that matches > where your source file was > > It's a fairly significant increase in mental overhead. It gets much > worse if the location of the shadow hierarchy root is configurable in > any way (e.g. based on sys.path contents or an environment variable). > > Restricting the caching mechanism to the folder containing the source > file keeps things a lot simpler. Great way of explaining why the basic folder-per-folder model wins over the folder-per-sys.path-entry model! The basic folder-per-folder model doesn't need to know what sys.path is. (And I hadn't followed previous messages in the thread with enough care to understand the subtlen implications of Ben's point. Sorry!) -- --Guido van Rossum (python.org/~guido)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4