Loading ...
Sorry, an error occurred while loading the content.

69706Re: Python items in the todo list

Expand Messages
  • Xavier de Gaye
    May 18, 2013
    • 0 Attachment
      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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Show all 26 messages in this topic