I'm not too thrilled about this, especially not in the 2.2 release cycle. The sys.path logic is difficult, and everytime a change was made on one platform this change immedeately broke things on all other platforms. For instance: on the Mac full pathnames are not necessarily unique. Or another example: on unix you could have your working directory in /foo/bar/bletch and access ./blurgh.py there, but not access /foo/bar/bletch/blurgh.py: /foo/bar could be unsearchable for you. And the "python -c" mod I really disagree with. 'python -c "import foo"' in the directory containing foo.py is the standard way of using this, which you would break.

I have been working on import.c and thinking about imports generally. Currently, the directory of the Python script is inserted into sys.path[0]. For example, "python /A/B/myscript.py" creates sys.path[0] = "/A/B", and "python myscript.py" creates sys.path[0] = "". But there are three problems.

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. It is clear that sys.path should not change unless the user changes it.

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.

If a command is entered using "-c", I don't think any insertion to sys.path should be made, as there is no indicated directory. Alternatively, the absolute path getcwd() should be inserted.

If everyone agrees, I will create a patch.

Jim Ahlstrom

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev

-- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm