воскресенье, 2 июня 2013 г., 2:51:35 UTC+4 пользователь MarcWeber написал: > @ZyX: I totally agree on plugin/ being a bad choice. And I also agree > that the patch is not perfect. I had to get it out due to Brams deadline > (Friday) - because otherwise much worse things could have happened - > people starting to use if py2 then .. else .. code which you cannot get > rid of. > > I also feel that we're not ready to know what is the perfect solution. > > I also think that the mailinglist is a good place to discuss, but not to > keep track of the results of a discussion. > > So what about moving it to a wiki? > > I've written down the topics I'm interested in: > http://vim-wiki.mawercer.de/wiki/vim74/improving-python-support-drafts.html > > And I'd like to integrate the drafts you've written earlier. Can you > tell me which is the most up to date information I should be working > with?
I have posted a link in that RFC thread to a gist with a draft: https://gist.github.com/ZyX-I/5561409. > > Next thing which is important to me is being able to use ctrl-c to abort > a python script. > > Marc Weber --- About solution with imp.load_source: it is not needed as you have execfile(filename, {}, {}) . Yes, this won't keep the scope, but you don't need to: all shared interfaces are to be defined in modules and if you post a closure somewhere outer scope is also saved thus there is no problem. You must not use imp.load_source because you don't need this module shared. It is completely fine in python to enforce some one best practice like it does with indentation, it is not perl with its TIMTOWTDI principle. And taking only one last path component when generating module name is far from the best idea. > try: > from vim.plugin.file_name import should not be there; > import __main__ > if hasattr(__main__, 'user_setting'): should either be replaced with `vim.vars` querying or with specific `vim.config` object similar to `c = get_config()` object found in IPython (I would really prefer the latter). Also note that with pip suggestion the only thing pyplugin should do is from foo import __vim_init__ __vim_init__() > I feel bad about forcing support for any solution. It should be optional > always. The same way we could provide ways to install exuberant-ctags for all > oses. Also using pip to check for packages is much more time consuming > (untested) than vam's test "does directory exist" to find out wether a plugin > is there? You have missed my message. **Pip is run if import fails.** You don't use pip to check for existence of the package. It does not matter how you installed the package since it can be imported, but using pip is the easiest way to install the plugin. If not pip what do you suggest. We must have built-in support for dependencies. VAM is not able to install python package (and is not a tiny bit standard solution). No other uniform solutions exist. Pip is the standard way of distributing files in python, thus having built-in support for pip is good (though with settings 'pythoninstallprg' and 'python3installprg' as for different python versions you have different pip executables and one may also want to replace default `pip install` with `easy_install`). Pip is also responsible for doing all necessary initialization (i.e. compilation of the sources) at installation or update. > vim.ensurep_python_library_exists('pip', 'foo') It is expected that package is installed by the time module is imported. It acts directly against "explicit is better the implicit" principle: imported module is not expected to do anything except for defining functions, classes and variables. It should not install something, or define options or create vim mappings/commands. At maximum it should initialize globals used e.g. for cache. Job is done by using defined functions or classes. > Also pip is the successor of easy_install. So even in the python community > things may change faster than Vim which could make it hard /impossible for > Vim maintainers to maintain such, too. This one is covered by 'python*installprg' settings. Though I thought about them only due to having four different pip executables for each of four python versions installed system-wide. Note that you can replace `pip install` prefix with `easy_install` almost always. Thus switching between them is changing one setting (and easy_install still works BTW). The suggested function does nothing more then calling `system(&pythoninstallprg . ' ' . (a:0 ? a:1 : shellescape(matchstr(a:module_name, '^[^.]\+'))))` in case of ImportError and retrying import thus changing to other installer is easy. -- -- 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.
