James - > > > This is incorrect. In Vim's current code, PySys_SetArgv is called with > > > an argv that is simply an empty string (and a terminating NULL > > > sentinel). This causes sys.path's first element to be the empty string, > > > thus causing any Python import statements to use Vim's current working > > > directory as the first location to check for the requested module. > > > > > > The filter specifically removes any elements in sys.path that evaluate > > > to false (i.e., the empty string). > > > > That is not what happens for me. Somehow somewhere the empty entry is > > changed to the full path of the directory above the current directory. > > I don't know where, but I see it happening. I have tried this with: > > > > :py import sys > > :py print sys.path > > > > > Using the attached print_sys.path.diff, the following is printed when I > > > start Vim (the sys.path before and after my suggested filter() command): > > > > > > ['', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', > > > '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', > > > '/usr/local/lib/python2.5/site-packages', > > > '/usr/lib/python2.5/site-packages'] > > > ['/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', > > > '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', > > > '/usr/local/lib/python2.5/site-packages', > > > '/usr/lib/python2.5/site-packages'] > > > > As mentioned, for me the first entry is not '' but a path. The filter > > command you suggested doesn't remove it. I don't know where the > > difference between our systems comes from. > > This is bizarre as I don't see how this could be happening in vanilla > Python code, so it seems like your install has been patched to add this > behavior. Either way, I see two options: > > 1) Save sys.path before calling PySys_SetArgv and restore it afterward. > 2) Prune the first element of sys.path after calling PySys_SetArgv. > > We know that PySys_SetArgv always adds an element to the front of > sys.path and we know that we're giving it a value that isn't valid (to > prevent a segfault in some warn() function I can't find a reference to). > > Adding an arbitrary, hopefully non-existent path in order to search for > and remove it just smells bad to me when there's defined behavior. My > initial idea when I got this bug was to simply do 2) but I changed to > the filter() patch later to be (I thought) more robust. > > I'd be interested in knowing where your Python install comes from so I > can see why it's behaving differently.
I'm using Python 2.5. The implementation of PySys_SetArgv() uses realpath(). It expands "" to the current directory. I haven't looked at the details, but I suspect that's what is causing the behavior I notice. You can see this file here: http://svn.python.org/view/python/trunk/Python/sysmodule.c?rev=64856&view=markup I think using a magic directory name works better than assuming something about the python code, e.g. prepending an entry to sys.path. A later version may correct the mistake and not change sys.path for an empty string. I think my version of the fix handles those situations. - Bram -- hundred-and-one symptoms of being an internet addict: 252. You vote for foreign officials. /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]