VimとPythonの補完についてのメモ¶
間をおくとすぐ忘れるので備忘録としてメモ。
前提¶
何かを貶めたりけなすような意図はありません。似たような問題に躓いたときに「そうゆうことだったのか」「こうすれば問題は回避できるんだな」みたいに思ってもらえたら嬉しいです。
pyenvやAnacondaの話はしません。
結論¶
VimのPython補完は davidhalter/jedi-vim: Using the jedi autocompletion library for VIM. で事足りる
virtualenv/venvを使用していればVimのPython/Python3インターフェースを両方ONにする必要がない(jedi-vimに関しては)
jedi-vimの補完で物足りなければPyCharm使うのも検討する
jediとは¶
最近LSP(Language Server Protocol)とかもでてきて気になったりしますが、Pythonの自動補完&静的解析ライブラリとして有名かつ定番なのが davidhalter/jedi: Awesome autocompletion and static analysis library for python. です。
これはJupyter NotebookやIPythonのインストール時にも一緒にインストールされますし、Vimに限らずEmacsやVSCode、AtomでもPythonの補完に使われています。 Vimではjedi-vimというプラグインを活用すると連携できますが、いくつか注意することがあるのでこの記事を書こうと思いました。
jedi-vimのインストール要件¶
VimのPythonインタフェースもしくはPython3インタフェースが有効になっていること と一点ですがこれが意外と曲者です。
PythonインタフェースもしくはPython3インタフェースを有効にするためには、以下の2つの条件を満たす必要があります。
Vimで
:version
した際に+python
もしくは+python3
になっているVimが必要としているPython(3)のバージョンをマイクロバージョン単位で合わせる必要がある
マイクロバージョンとはPython3.6.5の場合、3がメジャーバージョン、6がマイナーバージョン、最後の5がマイクロバージョンです (参考: 一般 Python FAQ — Python 3.6.5 ドキュメント )
たとえばUbuntu18.04LTS サーバー版の場合、Vimを起動すると :version
で -python/+python3
なのが確認できます。Ubuntu18.04LTSの場合はPython3.6.5がデフォルトでインストールされているため、 :python3 print('Hello')
とコマンドラインモードで入力すると Hello
と表示されるのが確認できます。大抵の場合 +python3
になっているVimを使っていれば問題ないでしょう。
しかしUbuntu18.04LTSのデスクトップ版の場合、最初に入っているVimは vim.tiny
と呼ばれVimで使える様々なオプションがOFFになっているため、 -python/-python3
になっています。この場合ターミナルから sudo apt install vim
のようにしてPythonインタフェースもしくはPython3インタフェースが有効になっているVimをインストールする必要があります。
OSが最初から用意しているVimとPythonを使えば問題ないこともあるのですが、次のように自分でVimやPythonを用意した際は問題になることがあります。
WindowsでVimは香り屋版Vimを使い、Pythonは www.python.org で入手した「最新の」Pythonを使う
macOSでVimはmacvim-kaoriyaを使い、PythonはHomebrewで入れている
つまりはVimが要求するPythonのバージョンを導入していないとVimが +python/+python3
になっていても、PythonがインストールされていてもPython/Python3インタフェースが有効にならない場合があります。これを避けるにはVimのリリースノートを見て、Vimが要求するPythonが導入されているか確認する必要があります。以下は一例です。
Windows版の香り屋Vimの場合: Releases - koron/vim-kaoriya
macvim-kaoriyaの場合: Releases - splhack/macvim-kaoriya
HomebrewでPythonを導入した場合¶
www.python.org から導入したPythonの場合はあまり心配がないのですが、HomebrewでPythonをインストールした場合macvim-kaoriyaが見る場所にPythonのパスが存在しないことがあって期待していた結果と異なる場合があります。そのような場合は MacVim-KaoriYa 20171221でPython3インターフェースが使えなくなっている · Issue #71 · splhack/macvim-kaoriya などを参考にして、シンボリックリンクを貼ると良いかもしれません。
jedi-vimのインストール方法¶
長々とVimとPythonの組み合わせについて話してきましたが、jedi-vimのインストールはVimのプラグインマネージャーを使用していれば簡単です。この記事では覚えることが少なくて済み、そこそこ高速に使える junegunn/vim-plug: Minimalist Vim Plugin Manager を使います。vim-plugのインストール方法はURLを参照してください。プラグインは ~/.cache/plugged
にインストールするものとします。
以下のようにvimrcでbeginとendの間に一行指定します。
call plug#begin('~/.cache/plugged')
Plug 'davidhalter/jedi-vim', {'for': 'python'} " pythonファイルを編集するときだけ起動
call plug#end()
記述し終えたらVimを再起動して :PlugInstall
すればjedi-vimがインストールされます。設定できるオプションはいくつかありますが、自分は以下のように設定しています。
set completeopt=menuone " 補完候補を呼び出すとき常にポップアップメニューを使う
autocmd! User jedi-vim call s:jedivim_hook() " vim-plugの遅延ロード呼び出し
function! s:jedivim_hook() " jedi-vimを使うときだけ呼び出す処理を関数化
let g:jedi#auto_initialization = 0 " 自動で実行される初期化処理を無効
let g:jedi#auto_vim_configuration = 0 " 'completeopt' オプションを上書きしない
let g:jedi#popup_on_dot = 0 " ドット(.)を入力したとき自動で補完しない
let g:jedi#popup_select_first = 0 " 補完候補の1番目を選択しない
let g:jedi#show_call_signatures = 0 " 関数の引数表示を無効(ポップアップのバグを踏んだことがあるため)
autocmd FileType python setlocal omnifunc=jedi#completions " 補完エンジンはjediを使う
endfunction
補完を使うにしろなるべく入力時の邪魔にならないように、必要なときに自分で呼び出すように設定しました。詳しくは :h jedi を参照してください。
jedi-vimのvirtuelenv/venvサポートについて¶
jedi-vimを入れたVimはデフォルトで有効になっているPython (Ubuntu18.04LTSだとPython3.6.5) に対して補完を行いますが、virtualenv/venvのような仮想環境を使用していると、仮想環境下で使用しているPythonを使用できます。Pythonのバージョンを気にする場合、仮想環境を作成して使うことがほとんどだと思うのでjedi-vimのvirtualenv/venvサポートは嬉しい限りです。
数年前はPython/Python3インタフェースが有効なPythonのバージョンでしか動かなかったようですが、現在はその制限はなくなりました。Python2.7のコードを書くために +python
と +python3
を両立した状態にしようとして自分でビルドする必要はないですし、vimrcに実行したいPythonのパスをPythonの2系と3系でそれぞれ指定する必要もありません。
どうしても +python
と +python3
を両立したいケースがあるとしたら +python
でしか動かない別のVimプラグインを使用したい場合や、すべてのVimのオプションをONにしたいような方だと思われます。普通にVimでPythonの補完を使いたい場合は +python3
になっているVimがあれば十分ですね。
標準のPythonのオムニ補完を使わない理由¶
「virtualenv/venvをサポートをしていないから」というだけで個人的には十分でした。逆にいうとVimがデフォルトで使うPythonだけ使い、標準ライブラリ以外は使わない場合はjedi-vimを入れる理由はないかもしれません。
jedi-vimの補完以外の機能¶
jedi-vimは補完機能以外にもさまざまな機能があります。気になる方はヘルプを見てみてください。
定義ジャンプ:
<Leader>d
変数リネーム:
<Leader>r
単語の使用箇所表示:
<Leader>n
pydoc表示:
<K>
モジュール表示:
:Pyimport {モジュール名}
PyCharmと比較して¶
単純に比べられないのですがPyCharmの優位な部分は多いと個人的には思います。PyCharmがVimの補完と比べて使いにくいなと思うのがキーワード補完やファイル名の補完などVim自体の補完が使えない点です。しかしそれ以上に、Pythonの標準ライブラリにとどまらず、PyPIからインストールしたライブラリに対してもヌルヌルと補完候補を絞り込んでくれます。また「あれなんだったっけ?」と思うようなところでもなんでもインクリメンタルに絞り込めるので単純ミスが少なくなるのがいいですね。
とはいえ自分だけで最初から最後まで書くようなときや、さっと何かを書いて試したいときはPyCharmの環境を準備するのが煩わしいときがあるので、そうゆうときはやはりVimを使ってしまいます。
補完だけの話ではなかったり、向き不向きや慣れの部分もあると思うので適材適所で使い分けていきたいです。
まとめ¶
VimのPython補完は davidhalter/jedi-vim: Using the jedi autocompletion library for VIM. で事足りる
virtualenv/venvを使用していれば、自分でVimをビルドする必要はない
jedi-vimの補完で物足りなければPyCharm使うのも検討する
最後に¶
この記事ではVimとPythonの補完について触れてきました。補完以外にも拡張したい項目があるかもしれませんが、それはひとまず他の記事に譲ることにします。また気が向いたらそのあたりの記事も描くかもしれません。
PyCon Kyushuで登壇してきました #PyCon9shu¶
去る6/30にLINE Fukuokaで開催されたPyCon Kyushuで登壇してきました。(本当はもっとはやくブログを書く予定でしたが7月に入り仕事が一気に忙しくなったのでゲフンゲフン)
30分というまとまった時間で、かつ誰かがモデレーターとして流れを作ってくれるわけでもない状況で登壇する機会ははじめてでしたが、発表する機会を与えてくださったことに感謝です。
イベントのURLは以下です。Togetterは探したところ見当たらなかったので作ってみました。
当日の様子をTweetとともに振り返っていきたいと思います。
フライト〜キーノートまで¶
https://twitter.com/kashew_nuts/status/1012806632282062848
東京は梅雨明けしていましたが、前日の九州は大雨ということで無事たどり着けるか不安でしたがなんとかアプローチ核心を超えました。
https://twitter.com/kashew_nuts/status/1012846537515257856
ちょうど祇園山笠のシーズンだったようで、迫力に圧倒されました。
https://twitter.com/kashew_nuts/status/1012856699311407104
まさかの並びに、会場入り直後にはちょっとテンション上がっていました。
https://twitter.com/kashew_nuts/status/1012864815558037505
なうとか言ってますが、このときはすでに発表のプレッシャーで緊張しておりテンパっていたのを覚えています。 「Python2時代のエンコーディング地獄」、「泡盛という飲み物を飲むとコーディング力が上がる」話が衝撃でした。
この直後スピーカーTシャツを受け取ったり、スライドを再度確認したりしていましたが、いよいよ緊張がピークでした。
発表に関して¶
PyCharmの便利な点、こうゆう使い方は向いてないよという点、使っているときに問題があったらどうするかなどをデモを交えながら話して来ました。
発表資料はこちらです Djangoで始めるPyCharm入門
いずれ動画が公開されるそうですが、現時点(7/15)ではまだ公開されていないようです。
発表の最中自分で時間を計るのをすっかり忘れており、タイムキーパーの方に「あと10分」の合図をされたときは「時間が足りない!」と思ったりしましたが(実は時間を計り間違えていて、残り15分あった)、途中軌道修正もしながらなんとか30分話し切ることができました。
質疑応答では予想していた通り、Community版とProfessional版の差やVSCodeとの違いについて質問されました。 期待する回答ができたかどうかはわかりませんが、少しでもPyCharmを使ってみようと思える人がいたらいいなと思います。
発表が終わった後Tweetを眺めていると概ね好評の感想が見られたので、ほっとしたのを覚えています。
反省点として英語のスライドにしておけばよかったかなーと思います。 意外と海外の方も見ていだけたりするみたいなので、次回発表する機会があれば(できる限り)英語スライドでやりたいと思います。
ランチタイム¶
https://twitter.com/kashew_nuts/status/1012908669955026944
午前中に発表を終えられたので、ランチタイムはリラックスしていろいろな方と話をさせてもらいました。 企業LTの時間はなぜかスプーンの話をしていたのが印象に残っています。
聴講したセッション¶
Introduce syntax and history of Python from 2.4 to 3.6 - slideship.com¶
@terapyon さんのコアPythonTalkでした。 コード例を見ながら「Pythonってこう書けるんだよ」という知識をアップデートできた時間でした。 Python3.5の @ 演算子やPython3.7のDataClassは便利そうだと感じましたし、それ以前からある機能も「なぜそれが良いのか」という知識の整理ができて非常に良かったです。
serverless framework + AWS Lambda with Python¶
@Masahito さんによるサーバレスフレームの話でした。 個人的にはサーバレスに関係なくあるあるネタが込められていて参考になることもありつつ、話の節々にでてくる「有名」や「好き」という単語に別の意味が込められている気がして非常に楽しい時間でした。
Artisanal Async Adventures¶
@ojiidotch による非同期処理がどのように動いているのかのライブコーディングタイム。みるみるうちに非同期で動くソケットプログラムができあがっていくのは圧巻でした。当日見せてくれたプログラムがどのように動くか確かめるのは宿題です。
クロージング¶
https://twitter.com/kashew_nuts/status/1012970841473146880
来年のPyCon Kyusuの開催場所が今年のKeynoteスピーカー @a_macbee さんから発表されました。継続していくイベントになっていくといいなーといち参加者として思いました。
懇親会<¶
スピーカーとして参加したおかげか、ぼっちにならずにいろいろな人と話せて楽しかったです。
何年か前からTwitterとかではつながっていたけれど、このイベントではじめてオフラインで会えた方もいましたし、 九州の方とPythonトークできたりしました。
Django ORM Cookbook というDjangoでORMを書くときに参考になりそうなドキュメントも教えていただきましたね。
https://twitter.com/shabda/status/1013468034382491649
(後日Founderの方からメンションをいただいたりして驚きました…)
Pythonプロフェッショナルプログラミング第3版 #pypro3 が出版されました¶
https://twitter.com/kashew_nuts/status/1004177465353179138
自分も執筆に携わった Pythonプロフェッショナルプログラミング 第3版 (略称PyPro3)が6/12に発売されました!
本の内容について¶
この本を一言でいうと「Pythonで仕事を進めていく上でのBeProudのノウハウを集めた本」です。 どんな内容か?何が改定されたのか?本のタイトルの意味などは、次の記事で詳しく説明されているのでそちらに譲ります。
一時はAmazonの開発技法ランキングで1位を獲得したようですね。
https://twitter.com/beproud_jp/status/1006447836773474304
何を担当したのか?¶
第6章「Git/Githubによるソースコード管理」の書き下ろし を担当しました。
書籍のレビューは何冊かかかわらせていただいたことがあるのですが、今回は初の執筆者として携わらせてもらいました。
本章の対象者¶
本章は次のことがわかり、なにかあったときも自分で解決への道筋がわかるようにと意識して書きました。
混同しがちなGitとGitHubの違いをおさえる
聞いたことはあっても実際には使ったことのないこともある、GitのコマンドやGitHub機能がわかるようになる
単にコマンドや機能の紹介で終わるのではなく、どうゆうときに使えばいいのかがわかるようになる
GitやGitHubに関する書籍や情報は巷にたくさんありますが、最後の「どうゆうときに使えばいいのかわかるようになる」よう焦点を当てて書きました。 これは自分自身が入社当時GitやGitHubの各コマンドや機能を調べるときに「これ」といえる情報を見つけるのが大変だったためです。
たとえばGitやGitHubを使ってはいても、例えば個人でしか使ったことのないような状態だと、次のような状態になることがあります。というか自分が以前なっていました。
「ほぼgit init, clone, add, commit, push, pullしか使っていない。ブランチもmaster一本で開発。」
「(なんとなく)GitやGitHubは使っているけど、実はコマンドや機能の意味がわからなくて使ってない」
「トラブって対応が面倒なときは、GitやGitHubのリポジトリを作り直す」
「なぜかgit pushできないときは、とりあえず git push -f」
「GUIのツールでGitを使ったりはするけど、実際何をやっているのか想像がつかない」
実際に仕事でかつチームでGitやGitHubを使うようになってからはそうゆうことするわけにもいかず、BPに入ってからは改めて学び直したのを覚えています。
本章では実際に仕事で必要になるコマンドや機能、そして実際にどの場面で使えばいいのかを自身で判断できるようにポイントを詰め込んでいます。 (説明のために図やコマンドの実行例も載せた結果、PyPro3が全488ページある中で6章だけで46ページとすべての章の中で一番ページ数が多くなってしまいましたが…)
執筆を通じて¶
はじめの頃違いがないようにと思って書いたところがうまく伝わらない文章になっていました。今回全体のマネージメントをしてくださった@takanoryさんから、「@kashew_nutsが書いたことっぽくない。レビューアー(としての)@kashew_nutsはどうした?」とフィードバックをもらうことがありました。心にくるものがありましたが、おかげで迷いながら書いていたところも吹っ切れてかけたと思います。(その後自分で何度か書き直してしまいましたが…)
他にも執筆中プロジェクトの仕事を助けてくださったプロジェクトメンバーの方々や、レビューアーとして厳しい意見やこうしたらもっと良くなると幾度となくアドバイスしてくださって本当にありがたかったです。
ぜひ読んでいただきたいところ¶
全部…なのですが、特にその中でも「Part2 チーム開発のサイクル」はぜひ読んでみてほしいですね。 PyPro3は15章の項目が全4Partにまとまっていますが、Part2はチーム開発で使うツール、課題管理システム、ドキュメンテーションなど普段なんとなく使っているものでも発見があったり、考え方の基準が書いてあったりして面白いです。