Hi James,
* James Vega <[EMAIL PROTECTED]> [2008-07-07 23:42]:
> 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 enough
>
> I think this is being addressed from the wrong perspective.Yes I agree, I would also be not really happy about this solution as all module writes would need to be aware of this problem. > 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. Do you think reassigning this to python would be appropriate? Thanks for the PEP links, I wasn't aware of them. Kind regards Nico -- Nico Golde - http://www.ngolde.de - [EMAIL PROTECTED] - GPG: 0x73647CFF For security reasons, all text in this mail is double-rot13 encrypted.
pgp4rm9O71Xbw.pgp
Description: PGP signature
