On Tue, 14 Nov 2000, Guido van Rossum wrote: > > How about > > <prefix>/lib/python<version>/Tools/idle > > instead. I suggest the change to support an until-now-implicit policy > > that anything in site-packages actually be a package. If things in > > site-packages aren't supposed to be packages, it ought to be called > > something like site-tools <0.2 wink>. > > Fine. Sorry, just noticed a problem with that: Say you put idle in .../Tools/idle And compiler in .../Tools/compiler Then the fact that some script does sys.path.insert(0, ".../Tools") means that it would get all the tools as packages to import, instead of only those it needs (say, for idle-callers, idle). That means a lot of backwards compat. issues. Why not have each tool be in things like ..../idle-support/idle/ And .../compiler/compiler-support/compiler, etc.? Actually, once we do that, why bring the Python path into that at all? "idle" is a program. The fact it is written in Python is incidental -- it might as well have been written in C, for all most users care. The FHS policy would seem to indicate that the support files would need to be in things like /usr/lib and /usr/local/lib Say, the default installation would put it in /usr/local/lib/idle-support/ and would add a line to sys.path.insert(), and put "idle" (the script) under autoconf control too. sorry-for-challenging-the-consensus-again-ly y'rs, Z. -- Moshe Zadka <moshez@math.huji.ac.il> -- 95855124 http://advogato.org/person/moshez
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