Rope becomes unusably slow in OSX Yosemite

[feoh]

At first I thought perhaps it was iTerm2 (where performance is so bad you can literally wait seconds for the completions to occur) so I groaned and switched back to OSX Terminal.

It's still pretty bad there - I'd sincerely appreciate the opportunity to help debug this problem. I don't know VimL (yet :) but I bought the book. I know Python, and I love this tool :)

For instance, upon typing this line:

self.assertNotIn('Use the Raspberry Pi to build a robot', page_text)

it took ropevim close to 40 seconds to actually 'render' the text and allow me to continue.

On the off chance someone else has seen this and knows of a fix though, I'd appreciate haring about that as well.

(FWIW I tried with stock OSX Python, homebrew Python 3 (shown here) stock OSX Vim, and homebrew built vim HEAD with python3 support (shown here))

Pymode diagnostic

VIM:704, OS: Darwin, multi_byte:1, pymode: 0.8.1, pymode-python: python3

+python: 0 +python3: 1

VIM python paths:

/Users/cpatti/.vim/bundle/python-mode/pymode/libs/pylama/lint/pylama_pyflakes /Users/cpatti/.vim/bundle/python-mode/pymode/libs3 /Users/cpatti/.vim/bundle/python-mode/pymode/libs /Users/cpatti/.vim/bundle/python-mode /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/setupto /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/pip-6.0 /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python34.zip /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4 /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/plat-darwin /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/lib-dynload /usr/local/Cellar/python3/3.4.2_1/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages vim_path

Pymode variables:

let pymode = 1 let pymode_breakpoint = 1 let pymode_breakpoint_bind = 'b' let pymode_doc = 1 let pymode_doc_bind = 'K' let pymode_folding = 1 let pymode_indent = 1 let pymode_lint = 1 let pymode_lint_checkers = ['pyflakes', 'pep8', 'mccabe'] let pymode_lint_cwindow = 1 let pymode_lint_ignore = '' let pymode_lint_message = 1 let pymode_lint_on_fly = 0 let pymode_lint_on_write = 1 let pymode_lint_select = '' let pymode_lint_signs = 1 let pymode_motion = 1 let pymode_options = 1 let pymode_paths = [] let pymode_quickfix_maxheight = 6 let pymode_quickfix_minheight = 3 let pymode_rope = 1 let pymode_run = 1 let pymode_run_bind = 'r' let pymode_trim_whitespaces = 1 let pymode_virtualenv = 1 let pymode_virtualenv_enabled = '' let pymode_virtualenv_path = ''

[mcepl]

Could you please uninstall python-mode (if you use Pathogen (and you should), then remove it from ~/.vim/bundle/ or its equivalent), and install rope, ropemode, and ropevim from the Git repos here (follow the instructions , and test again.

@aligrudi Do we have any testing script which could be run with profile?

[feoh]

@mcepl Please check out the attached issue. The problem was fixed by upgrading the rope libraries to the latest.

Unfortunately the python-mode author is either busy, asleep at the switch, or has abandoned ship, because the pull request to update these libs to the latest has been languishing for a while. See attached issue on that project:

https://github.com/klen/python-mode/issues/537

for more details.

[mcepl]

OK, I don’t want to say anything bad about “competition”, but it seems to me that python-mode is at the best collection of the third party modules (pylint, rope, pydoc, pyflakes, pep8, and mccabe; something else?; pylama seems to me really obscene … with it python-mode is a shell over shell over shell (flake8) over third party library) stitched together. How much code there is of their own?

Yes, it is more convenient to have this all together bundled by somebody, but you then depend on that somebody to keep all modules up-to-date (it would be actually lovely, if he could just use those third-party libraries as git submodules) and communicate all issues upstream. I use all those libraries directly from their original owners and I think I have less problems this way. Of course, the other alternative is to fork python-mode and maintain it yourself (but then, please, really make those third-party libraries into submodules; I am very much willing to accommodate any reasonable requests which would make your life easier).