On Thu, Nov 13, 2008 at 11:23:07AM +0100, Bram Moolenaar wrote: > > 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. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
