69743Re: Python items in the todo list
- May 19, 2013On Sat, May 18, 2013 at 4:12 PM, ZyX wrote:
>>>> Interesting. So we would have a $VIMRUNTIME/python directory and we canI think that it is reasonable to answer to anyone that complains
>>>> 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
>> >>> import os, posix
>> >>> os.chdir is posix.chdir
>>`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
> 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
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
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.
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 vim_dev+unsubscribe@....
For more options, visit https://groups.google.com/groups/opt_out.
- << Previous post in topic