Gordon McMillan wrote: > > Jim "Fortran" Ahlstrom wrote: > > This insertion occurs after a number of imports have already > > occurred. Specifically, it occurs after the import of site, os, > > and sitecustomize. This is confusing. > > Why? site happens before Python even thinks about > sys.argv[0]. By it's very name it's about "how this installation > should behave", not "how a script in this directory behaves". Adding the directory of the Python script occurs after a number of imports have already happened. This is not necessary. The directory of the script is known. It is confusing because the programmer sees that the script directory is the first item of sys.path, and so concludes that [s]he can put scripts there and have them imported. This sometimes works, but fails for os, site, sitecustomize and a few others. There is no reason for this other that accidental details of the implementation. Think of documenting imports. We would need to explain that sys.argv[0] is Special, and different from other items. Yuk. The programmer may indeed manipluate sys.path, but at least Python's default path should be simple. BTW, is there any documentation on the details of imports, even a description of sys.path? We need an "invocation and imports" manual (which I guess I just volunteered to write). > > If no path component is given, the zero length string is > > inserted. But if the current working directory later > > changes, this is no longer valid. If we want the directory > > of the script to be sys.path[0], then an absolute path should be > > inserted. > > Some people os.chdir() just for this effect. I don't think I mind if > they experience some pain <wink>. This is a problem for zip imports and directory caching. If an item of sys.path is a relative path, and getcwd() changes, then it is difficult (as in slow, not as in impossible) to get caching to work. Think of sys.path item "./archive.zip". There is a dictionary full of items starting with "./", and then CWD changes. I would have to recognize a relative path for any item of sys.path, and call getcwd() for each one, all for each supported OS. Not fun. Using my current code, zip imports fail if a relative path is given and getcwd() changes. This is a problem especially on Windows, as normally the CWD changes to the directory of an opened file. I think most of the practical problems go away if sys.path[0] is an absolute path. Then I can either make relative paths work with the penalty that imports will be slower, or write documentation that sys.path[] must only contain absolute paths. In either case, I think sys.path[0] should be an absolute path. Again, think about documenting imports. What is sys.path[0]? It is the directory of the script. This is a fixed directory that doesn't change. JimA
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