Dieter Maurer wrote: ..... > > The question was: > > "should python start up with **non-existent** objects on the path". > > I think there is no reason why path needs to contain an object > which does not exist (at the time the interpreter starts). > > In your use case, "python24.zip" does exist and therefore may > be on the path. When "python24.zip" does not exist, it does > not contain anything and especially not "site.py". >
I think this was my intention, but also I think I have some concern over having two possible locations for the standard library. It seems non pythonic and liable to cause confusion if some package should manage to install python24.zip while I believe that python24\lib is being used. > > I recently analysed excessive import times and > saw thousands of costly and unneccesary filesystem operations due to: > > * long "sys.path", especially containing non-existing objects > > Although non-existent, about 5 filesystem operations are > tried on them for any module not yet located. > > * a severe weakness in Python's import hook treatment > > When there is an importer "i" for a path "p" and > this importer cannot find module "m", then "p" is > treated as a directory and 5 file system operations > are tried to locate "p/m". Of course, all of them fail > when "p" happens to be a zip archive. > > > Dieter I suppose that's a reason for eliminating duplicates and non-existent entries. -- Robin Becker -- http://mail.python.org/mailman/listinfo/python-list