>>> 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. >> 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`. -- -- 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.
