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

69743Re: Python items in the todo list

Expand Messages
  • Xavier de Gaye
    May 19, 2013
      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
      > 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.


      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