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

Re: pythonx patch - :pyx command

Expand Messages
  • ZyX ZyX
    ... It is vim coding style You may use what you want in your projects, but when writing patches for existing one do use existing style. ... I read this as let
    Message 1 of 35 , Jun 1, 2013


      On Jun 1, 2013 7:43 AM, "Marc Weber" <marco-oweber@...> wrote:
      >
      > ZyX: Usually you're rigth with what you're saying.
      > So please help find the best forum to place your "style guides" about
      > "how to write unobstrusive perfect python based vim plugins".
      >
      > You all know that I've introduced this wiki:
      > http://vim-wiki.mawercer.de/
      >
      > I think such (and making such official) would be the best way to tell
      > users how to write plugins - it should be open to everyone and it should
      > be available offline.
      >
      > Whether I use tabs or spaces is not visible to users.
      > Making python scripts interruptable is more important to me.

      It is vim coding style You may use what you want in your projects, but when writing patches for existing one do use existing style.

      > > AFAIK that was discussed. Do use pyplugin/ and set this on by default.
      > > In the current state I will never turn this option on and will suggest
      > > everybody turn it off immediately I see it. It is not the user who
      > > chooses whether this option can be turned on, but plugin writers.
      > There is no reason to introduce yet another directory people have to
      > remember. Keep things simple. Plugins will adopt soon.
      >
      > I read the rule as "everything you put into plugin/* will be sourced"
      > Its simple and understandable. If plugins don't follow this rule, they
      > can be changed easily.
      > Its an implementation detail we can discuss.

      I read this as "let us introduce problems without reason". Being disabled by default this option will force plugin writers still have plugin/*.vim file.

      I would really prefer pyload() described earlier with pip as a plugin manager.

      > j And third, you must not use the same code as :pyfile. It is already
      > > bad that somebody may think that creating large file sourced using
      > > :pyfile is a good idea: it is never a good idea because file executed
      > > via :pyfile is executed as a part of __main__ package polluting global
      > > scope.
      > Maybe you want it. Its what plugins do: define interfaces for others?

      No. When python developer wants to define interfaces he uses importable modules. In the current state it only rises probability of conflict.

      > I have never used :pyfile and would suggest anybody against it.
      > > With autoloading *.py files using the same code you run into the same
      > > issue.
      > So, what would you do instead?
      > plugins/*.vim files also pollute global space, it depends on the user
      > how he/she uses it.

      plugin/*.vim have s:. Python has nothing like this.

      > I don't think this forum is the right place to write up about this.
      > I think the :h if_pyth.txt is  - or an official wiki.
      >
      > > Even with the latter fixed I would only put some necessary initialization into such files thus
      > > b) I would merge this at the same time with merging `sys.path`
      > > addition once it is implemented.
      > I've thought about this again and I think plugins can do this themselves
      > as needed, eg using __FILE__ constant easily.
      >
      > ZyX: Can you explain once gain how you'd prevent plugins from polluting
      > global scope while letting plugins author to define their own stuff?

      "Polluting" here means that you make *all* auxiliary stuff in global scope. Not polluting means that you push nothing into __main__ and only UI parts into vim global scope.

      In pyplugin/* you should do two things: import modules placed in python/* and use imported stuff to define UI: like this:

      from foo import mapfuncs
      import vim

      for (mapname, mapmode, defaultlhs, mapdescr) in mapfuncs:
          lhs=vim.vars.get('foo_map_' + mapname, defaultlhs)
          map=vim.Mapping(**mapdescr)
          vim.mappings[mapmode][lhs]=map

      # similar cycle for commands, autocommands and menus

      > Should we run such code:
      >
      >   http://stackoverflow.com/questions/67631/how-to-import-a-module-given-the-full-path
      >
      >   import imp
      >   imp.load_source('module.name', '/path/to/file.py')
      >
      > This would mean that contents in path/to/file.py would be local to
      > module module.name
      >
      > But then we have to think about how to allow sharing - eg privde a
      > module vim_shared whichs sole purpose is to share a global dictionary?

      You do share things in python by creating importable modules. Files in pyplugin/ must not contain anything to share. E.g. define this dictionary in python/foo.py and use it in other plugins by doing "from foo import bar_dict". Don't pull bad habits from VimL to python, *python developers already created everything you need*.

      > Marc Weber
      >
      > --
      > --
      > 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.
      >
      >

      --
      --
      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.
       
       
    • Bram Moolenaar
      ... I have included the patch now. I had to change the text for sys.version as well, on my system it returns more text after the version number, specifically
      Message 35 of 35 , Jan 28
        Ken Takata wrote:

        > 2017/1/26 Thu 0:56:50 UTC+9 Ken Takata wrote:
        > > Hi Bram,
        > >
        > > 2017/1/25 Wed 1:49:14 UTC+9 Bram Moolenaar wrote:
        > > > Ken Takata wrote:
        > > >
        > > > > > Hmm, having a has() call have side effects is unexpected. I would think
        > > > > > that has('pythonx') just returns 1 if python 2 or 3 is available, thus
        > > > > > that a :pyx command is expected to work. I suppose we do need to try
        > > > > > dynamic loading to find out if it succeeds, which in some cases would
        > > > > > mean the other version can't be used (when python 2 and 3 can't both be
        > > > > > loaded).
        > > > >
        > > > > The reason of the side effect of has('pythonx') is, as you said, some systems
        > > > > don't allow to load both python 2 and 3. Basically, has() should not have
        > > > > side effects, but unfortunately has('python') and has('python3') already
        > > > > have side effects...
        > > > > If has('pythonx') doesn't try dynamic loading, it might return wrong result
        > > > > when both python 2 and 3 DLLs were not available. This is also unexpected.
        > > > > So I think there are two choices:
        > > > >
        > > > > 1. Allow the side effect of has('pythonx'), or
        > > > > 2. Disallow to set 'pyx' to 0. Vim does not detect python 2 or 3
        > > > > automatically. It checks only the specified version.
        > > > >
        > > > > What do you think?
        > > >
        > > > We do want has() to return a useful result. We should document the
        > > > behavior, and say that if the user has a preference he should use has()
        > > > on his preferred python version first. So in your .vimrc:
        > > >
        > > > call has('python3') " prefer Python 3 if available
        > > >
        > > > Then the next:
        > > >
        > > > if has('pythonx')
        > > >
        > > > In a plugin would use Python 3 if available, but fall back to Python 2
        > > > otherwise.
        > >
        > > I'm afraid that this doesn't work as expected.
        > > I consider a different way.
        > >
        > > When compiled only with one of +python or +python3:
        > >
        > > * All pyx* commands and functions work with the compiled version of python.
        > >
        > >
        > > When compiled with both +python and +python3:
        > >
        > > * If 'pyx' is set to 2 or 3, all pyx* commands and functions work with the
        > > specified version. Calling has('pythonx') checks the specified version only.
        > > * If 'pyx' is 0, has('pythonx') tries to load python 3 first, then python 2.
        > > Calling has() will not change the 'pyx' setting. All pyx* commands and
        > > functions also try to load python 3 first, then python 2, and also set 'pyx'
        > > to 3 or 2 if it is loaded successfully.
        > > * If a user prefers python 3 and want to fallback to 2, he doesn't need to
        > > set anything.
        > > * If a user prefers python 2 and want to fallback to 3, he needs to check
        > > explicitly in his .vimrc:
        > >
        > > if has('python')
        > > set pyx=2
        > > elseif has('python3')
        > > set pyx=3
        > > endif
        > >
        > >
        > > Updated patch is attached.
        >
        > I found that the pyxdo test failed on Linux because of different output format
        > of `sys.version`.
        > I have updated the patch. Please find the attached patch.

        I have included the patch now. I had to change the text for sys.version
        as well, on my system it returns more text after the version number,
        specifically a plus sign.

        --
        The early bird gets the worm. If you want something else for
        breakfast, get up later.

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
        \\\ an exciting new programming language -- http://www.Zimbu.org ///
        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

        --
        --
        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/d/optout.
      Your message has been successfully submitted and would be delivered to recipients shortly.