Bug#484305: PoC not working for bicyclerepair
James Vega
jamessan at debian.org
Tue Jul 8 20:51:25 UTC 2008
On Tue, Jul 08, 2008 at 10:18:46PM +0200, Nico Golde wrote:
> Hi James,
> * James Vega <jamessan at jamessan.com> [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?
That would probably be a better place for it, yes. I definitely don't
think it's a bug in Vim or the specific Vim script and I'm unsure
whether it's truly a bug in Python or just less-than-ideal behavior.
Even with the listed PEPs implemented, it sounds like this behavior is
still possible, just not as likely.
--
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/20080708/01495be2/attachment.pgp
More information about the pkg-vim-maintainers
mailing list