On Fri, May 17, 2013 at 9:07 PM, ZyX wrote:
>> Interesting. So we would have a $VIMRUNTIME/python directory and we can
>> put Python scripts there that we include with the distribution.
>>
>> I'm sure it is only a small step that users will ask to have a python
>> directory in ~/.vim/python. Or more general, using 'runtimepath'.
>>
>> Then a plugin does not require to have its Python code in between a
>> :python << EOF and EOF. That would be a lot nicer, right?
>>
>> What do others think?
>
> Automatically adding all items from `&rtp` to sys.path would be
> good. It (and python3/) is already a standard directory in frawor
> for python files.
>
> But I would vote against the patch to os.chdir implemented in python
> and (as there is no better variant) for the solution based on
> comparing current directories before and after `os.chdir`:
>
> 1. Implementation based on comparing current directories can be
> written once and easily applied to all other interfaces.
> 2. `os.chdir` is most common, but not the only way to change
> directories from python: there are also at least `posix.chdir` and
`os.chdir` and `posix.chdir` are two names that are bound to the same
built-in function, as you can check with:
>>> import os, posix
>>> os.chdir is posix.chdir
True
`posix.chdir` is low level and is never used. The python documentation
on 'posix' states:
"Do not import this module directly. Instead, import the module os".
`posix.chdir` is not even listed in the python documentation.
> calls to libc (e.g. indirectly from some bindings or directly using
> ctypes, though I can’t imagine why the latter may be required).
This is kind of a red herring as the same issue already exists with
the vimL libcall() function.
> 3. Proposed implementation will break once somebody deletes `os`
> from sys.modules for some reason (I used to use this variant to
> reset `os` module after mocking its methods for testing purposes;
> though as for all non-builtin modules touching `sys.modules`).
It is not good practice to import a module twice (unless you own it
and thus, know what you are doing) because importing a module may have
side effects: when you import a module, you execute all the statements
within the module, and executing them twice might not have been
expected by the author of the module.
If you mock some 'os' methods for testing purposes, then, when you are
done with it, you must restore those methods instead of deleting the
module from sys.modules and re-importing it a second time which is not
safe.
> About the implementation of `&rtp` handling: you can add there to
> `sys.path` a special path like `'_vim_runtimepaths_'` and add hook
> to `sys.path_hooks` that can handle it. Requires dropping python 2.2
> support (`path_hooks` were added in python 2.3), but you won’t then
> need to hack `options.c` to add or remove appropriate paths from
> `sys.path` when changing `&rtp`.
--
Xavier
Les Chemins de Lokoti: http://lokoti.alwaysdata.net
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
