On Sat, May 18, 2013 at 4:12 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:
>
> This does not matter. When you assign to `os.chdir` they are no longer
> identical.
>
>> >>> 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.
>
> libcall() can use the same function for checking for os.chdir.
>
>>> 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.
>
> `os` seems to be safe regarding the issue.
>
>>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.
>
> Yes, I changed the implementation immediately after I found that removing from
> `sys.modules` may introduce strange TypeErrors (objects in module got assigned
> None). I have never seen such behavior for C modules though, only for python
> ones.
I think that it is reasonable to answer to anyone that complains
something is broken after he deletes a module from sys.modules and
re-import it again:
"Please don't do that, if you really need to do it, then you are
on your own".
For example with the 'sys' module in the vim-python interface ('sys' is
a C extension module by the way):
:py3 import sys; del sys.modules['sys']
:py3 import sys
:py3 print(sys.stdout)
Traceback (most recent call last):
File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'stdout'
Press ENTER or type command to continue
Re-binding a name such as done in the patch with os.chdir is actually
quite common. It is even already done in the current vim-python
interface with sys.stdout and sys.stderr (see PythonIO_Init_io()). A
vim user writing a python program with the vim-python interface may
also re-bind sys.stdout and sys.stderr to implement i/o redirection,
but he is expected to restore the original bindings after he is done
and certainly must not delete the 'sys' module and re-import it again.
--
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.
