Roland Puntaier wrote:

> On 08/19/2011 10:29 PM, Bram Moolenaar wrote:
> > Roland Puntaier wrote:
> >
> >> E836: This Vim cannot execute :python after using :py3
> >> This happened to me several times already when changing to a buffer with
> >> python code, e.g. to my .vimrc file. The reason was that omnifunc was
> >> set to pythoncomplete#Complete.
> Correction: the reason was that has("python") issued the error if I had 
> used :py3.
> >>
> >> Python 2.6 and python 2.7 have had changes to make it more compatible
> >> with python3. It is now quite easy to write code that works for both,
> >> python2.x and python3.x.
> > You mean Python 2.6, 2.7 and 3.x.  Not for Python 2.5 and earlier.
> >
> >> With the error message triggering and the latter thought I tried to go
> >> for the following: forward to the other python command.
> >>
> >> - The first time vim realizes that it cannot run python (py3) because of
> >> the RTLD problem this error message is issued:
> >>
> >>           E836: This Vim cannot execute :python after using :py3. Will
> >> forward future calls to :py3.
> >> or
> >>           E837: This Vim cannot execute :py3 after using :python. Will
> >> forward future calls to python.
> >>
> >>     (Of course, I've not changed the translations of the these messages.)
> >> - The second time the python command is forwarded to the other python
> >> command
> >> - If the system/python version allows both, python 2.x and python 3.x,
> >> there is no forwarding.
> >> - This applies only if vim is configure for both python versions
> >>
> >> If somebody has a script, which uses either :py3 or :python, the
> >> following sequence in the .vimrc as first python interaction will
> >> redirect all calls to :py3.
> >>
> >>       "redirect :python to :py3
> >>       py3 3
> >>       python 2
> >>       "argument has no meaning
> >>
> >> If the order is changed :py3 calls will be redirected to :python.
> >>
> >> @Bram: If you agree, please merge it to the main vim line.
> >>
> >> @Aaron: Since the changes in python3complete.vim do work for python 2.6
> >> and python 2.7 (I've test it), I have moved it to pythoncomplete.vim.
> >> The patch contains this move. The original pythoncomplete.vim I've moved
> >> to python25complete.vim with according internal renaming. It is attached.
> >> Do you agree with this proceeding?
> >> I'm moving to ArchLinux and in the vim package there pythoncomplete.vim
> >> is separate. The same version is already included in the vim sources.
> > I know quite a few people use Python 2.4, because some scripts don't
> > work with later versions.
> This is about my change in pythoncomplete.vim.
> I agree.
> 
> @Aaron: No change regarding pythoncomplete.vim and python3complete.vim.
> 
> > I don't like getting an error only the first time something goes wrong,
> > it can easily be missed.
> >
> > Why not add a way to ask Vim what Python versions are available.  This
> > can use PYTHON_API_VERSION or PY_VERSION_HEX.  Depending on that a
> > script can try loading the version it wants and check with has() if it's
> > actually available.  Then define a user command with :py3 or :python, as
> > desired.  Or give an error message if the Python version is not
> > supported.
> >
> > Something like:
> >
> >       if pythonversion() =~ '2\.[67]'&&  has('python')
> >         command Pyt python
> >       elseif pythonversion() =~ '3\.'&&  has('python3')
> >         command Pyt py3
> >       else
> >         echoerr "No usable Python version"
> >       endif
> 
> A function like
>      
> interpreter_version('lua'|'mzscheme'|'perl'|'python'|'python3'|'ruby'|'tcl')
> wouldn't harm, but it's not needed.
> If we know whether Python2 or Python3 then the rest can be found out by 
> a Python script.
> The same is true for the other interpreters, else such a function would 
> have been missed.
> 
> It is enough when has() takes into account the case where
> both 2.x and 3.x are configured but only one can be active per VIM 
> instance.
> *Then has() should return true only for the active one and not issue an 
> error.*
> 
> The change in has() and some little adaptations in vim files are attached.

That's copying code unneccessarily.  The EMSG in
python_runtime_link_init() is lacking a check for the verbose argument.
See patch below.

This still has the problem that just checking for python or python3
being available loads the library before knowing what version it is.
Thus a plugin checking for python causes python to be loaded and thereby
disabling python3.

Perhaps we don't care?  At least the user can put has('python3') in his
vimrc to force loading the preferred version.


*** ../vim-7.3.285/src/if_python.c      2011-06-19 00:27:46.000000000 +0200
--- src/if_python.c     2011-08-21 17:03:52.000000000 +0200
***************
*** 368,374 ****
       * standard C extension libraries of one or both python versions. */
      if (python3_loaded())
      {
!       EMSG(_("E836: This Vim cannot execute :python after using :py3"));
        return FAIL;
      }
  #endif
--- 368,375 ----
       * standard C extension libraries of one or both python versions. */
      if (python3_loaded())
      {
!       if (verbose)
!           EMSG(_("E836: This Vim cannot execute :python after using :py3"));
        return FAIL;
      }
  #endif
*** ../vim-7.3.285/src/if_python3.c     2011-07-15 15:54:39.000000000 +0200
--- src/if_python3.c    2011-08-21 17:05:19.000000000 +0200
***************
*** 367,373 ****
       * standard C extension libraries of one or both python versions. */
      if (python_loaded())
      {
!       EMSG(_("E837: This Vim cannot execute :py3 after using :python"));
        return FAIL;
      }
  # endif
--- 367,374 ----
       * standard C extension libraries of one or both python versions. */
      if (python_loaded())
      {
!       if (verbose)
!           EMSG(_("E837: This Vim cannot execute :py3 after using :python"));
        return FAIL;
      }
  # endif


-- 
ARTHUR: If you do not open these doors, we will take this castle by force ...
   [A bucket of slops land on ARTHUR.  He tries to retain his dignity.]
                 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- [email protected] -- 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

Raspunde prin e-mail lui