On Mon, Jul 07, 2008 at 10:15:44PM +0200, Nico Golde wrote:
> Can you think of a better solution than the following?
> --- /usr/share/vim/addons/plugin/bike.vim 2008-07-07 22:14:28.000000000
> +0200
> +++ bike.vim.new 2008-07-07 22:14:26.000000000 +0200
> @@ -100,6 +100,7 @@
> try:
> if sys.version_info < (2, 2):
> raise ImportError, 'Bicycle Repair Man needs Python 2.2 or newer'
> + sys.path.remove('')
> import bike
> bikectx = bike.init()
> bikectx.isLoaded # make sure bike package is recent enoughI think this is being addressed from the wrong perspective. This is a Python problem. Performing "import compiler", where compiler is a module in the std-lib and performs its own import of another std-lib module should not cause the module in the user's working directory to be imported instead. As evidenced by PEP 328[0] and PEP 366[1], this is an acknowledged problem upstream and they're working to address it. As for what that means for the current bug, this is something that python users have to deal with when they have a file whose name conflicts with one in the std-lib. This also means that the *only* time users will run into issues like this are specifically when they have a filename in Vim's working directory that conflicts with the name of a Python module. [0] - http://www.python.org/dev/peps/pep-0328/ [1] - http://www.python.org/dev/peps/pep-0366/ -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
