Bug#484305: PoC not working for bicyclerepair

[James Vega]

On Mon, Jul 07, 2008 at 09:16:21PM +0200, Nico Golde wrote:
> Hi James,
> * James Vega <jamessan at debian.org> [2008-07-07 20:11]:
> > On Mon, Jul 07, 2008 at 07:11:10PM +0200, Nico Golde wrote:
> > > I am also not really sure what is causing the automatic 
> > > import.
> > 
> > Python, by default, has '' as the initial item in its sys.path list
> > 
> >   $ python
> >   Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
> >   [GCC 4.3.1] on linux2
> >   Type "help", "copyright", "credits" or "license" for more information.
> >   >>> import sys
> >   >>> sys.path
> >   ['', '/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/site-packages/Numeric', '/usr/lib/python2.5/site-packages/gst-0.10', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0']
> > 
> > This means that anything in the current directory is first priority when
> > trying to use/import a module.
> 
> This should only happen in an interactive session, not!?
> nion at coredump:/tmp$] mkdir somedir
> [nion at coredump:/tmp$] cd somedir
> [nion at coredump:somedir$] cat > /tmp/test.py << EOF
> heredoc> import sys
> heredoc> print sys.path
> heredoc> EOF
> [nion at coredump:somedir$] python /tmp/test.py
> ['/tmp', '/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/site-packages/Numeric', '/usr/lib/python2.5/site-packages/PIL', '/var/lib/python-support/python2.5', '/var/lib/python-support/python2.5/gtk-2.0', '/usr/lib/python2.5/site-packages/wx-2.6-gtk2-unicode']
> 
> The python docs also state "As initialized upon program startup, the first item
> of this list, path[0], is the directory containing the script that was used to
> invoke the Python interpreter."

In an interactive session, sys.path[0] is '' because the "script" is
simply the python interpreter.  In your example, if you were in /tmp
when you ran test.py you would have seen '' as sys.path[0] as well.

In the case of Vim, sys.path[0] is always Vim's current working
directory.

/tmp $ mkdir somedir
/tmp $ cat test.vim
function! ShowPath()
    python << EOF
import os
import sys
print os.getcwd()
print repr(sys.path[0])
EOF
endfunction
call ShowPath()
cd somedir
call ShowPath()
q
/tmp $ python -S test.vim
/tmp
''
/tmp/somedir
''

From what I can tell, every time the :python command (which is simply a
thin wrapper to the PyRun_SimpleString function from Python's library)
is run from Vim, it's like running a new script.

This would explain why why sys.path[0] and os.getcwd() are updated when
we change the current working directory of the Vim process.

-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20080707/89c195e2/attachment.pgp