Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
[Pycon Kyushu 2019] Pythonでの開発を効率的に進めるためのツール設定
Search
Atsushi Odagiri
May 18, 2019
Technology
9
46k
[Pycon Kyushu 2019] Pythonでの開発を効率的に進めるためのツール設定
Atsushi Odagiri
May 18, 2019
Tweet
Share
More Decks by Atsushi Odagiri
See All by Atsushi Odagiri
setuptoolsの最近
aodag
1
2.4k
あなたとPython今すぐパッケージング
aodag
2
3.6k
LL2018 LT Pythonパッケージマネージャーはどれがおすすめ?
aodag
2
1.6k
Other Decks in Technology
See All in Technology
DevOps文化を育むQA 〜カルチャーバブルを生み出す戦略〜 / 20250317 Atsushi Funahashi
shift_evolve
1
120
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
770
20250325_Logic Apps / Power Automate の SharePoint コネクタの裏側を知る 〜Graph APIで直接操作してみよう〜
yutakaosada
0
110
AIエージェントの地上戦 〜開発計画と運用実践 / 2025/04/08 Findy W&Bミートアップ #19
smiyawaki0820
17
4.2k
OPENLOGI Company Profile
hr01
0
62k
20250326_管理ツールの権限管理で改善したこと
sasata299
1
580
バックエンド留学した話/Backend study abroad story
kaonavi
0
120
職種に名前が付く、ということ/The fact that a job title has a name
bitkey
1
270
Symfony in 2025: Scaling to 0
fabpot
2
270
TopAppBar Composableをカスタムする
hunachi
0
170
小さく始めるDevOps 内製化支援から見えたDevOpsの始め方 / 20250317 Ken Takayanagi
shift_evolve
1
120
Enterprise AI in 2025?
pamelafox
0
130
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Designing for Performance
lara
606
69k
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
GraphQLとの向き合い方2022年版
quramy
45
14k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
160
15k
Building Adaptive Systems
keathley
41
2.5k
For a Future-Friendly Web
brad_frost
176
9.6k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
8
720
Product Roadmaps are Hard
iamctodd
PRO
52
11k
Fireside Chat
paigeccino
37
3.4k
Building Applications with DynamoDB
mza
94
6.3k
Transcript
Python での開発を効率的に進めるためのツー ル設定 Pycon Kyushu 2019 Atushi Odagiri May 18,
2019
Outline はじめに プログラミングエディター コード補完/クオリティチェック/フォーマッタ テスト/デバッグ/プロファイル タスクランナー プロジェクトテンプレート まとめ
お前誰よ aodag open collector pylonsproject.jp
Python 開発ツール クオリティチェック/コード補完/フォーマッタ テスト/デバッグ/プロファイル タスクランナー プログラミングエディター
エディターに望む機能 シンタックスハイライト 賢い補完 静的チェックの結果表示 スニペットの展開 プログラム可能な機能
優秀なプログラミングエディター emacs vim visual studio code pycharm
コード補完 jedi 他に…知らない
jedi コード補完のエンジン いろんなエディタの補完プラグインから呼べる 名前についてはご愛敬
コード補完をもっとうまくやる typing annotation 特に引数につけないと関数内で補完効かない . の連鎖を減らす a.b.c.d など連鎖すると type annotation
がない場合、補完で きる可能性が低くなります
クオリティチェック flake8 おすすめ pylint mypy
pylint pylint は厳しすぎ メソッド数の下限上限 例えばコンストラクタだけのオーバーライドなど禁止 その場しのぎの回避もまた別のチェックにひっかかる 全体的な設計変更に…
flake8 pycodestyle + pyflakes フォーマッタ使うと pycodestyle 部分はそれほど.. pyflakes やってしまいがちなケアレスミスのチェック 宣言のない変数
関数名の重複 利用していない変数 … おすすめというかもはや必須
mypy type annotation のチェック jedi での補完目的で type annotation するなら必ず mypy
で チェックしましょう ignore_missing_imports は必須! type annotation を提供してないライブラリは多いので… docstring でがんばって型を説明するくらいなら annotation にしてほしいところ
フォーマッタ autopep8 yapf black おすすめ isort おすすめ
black のいいところ ほとんど設定変更できない 諦めがつく へんな亜流が出てこない
black のよくわからないところ なぜか行の最大長が 88 文字
その import、ソートできますか? isort は import 文の順番に特化したフォーマッタ 標準ライブラリ、サードパーティライブラリ、開発中ソース ツリーの順になおしてくれる これでエラー出たり、挙動が変わるなら循環依存があるので なんとかしましょう
black と isort を組み合わせる デフォルトだと black のフォーマットと違う isort のスタイル設定を black
に合わせる Vertical Hanging Indent multi_line_output=3 isort の行の長さを black に合わせる line_length=88
isort (3: Vertical Hanging Indent) from third_party import ( lib1,
lib2, lib3, lib4, )
black と flake8 flake8 の独自解釈が black のフォーマットと衝突する 演算子の改行位置 W503 line
break before binary operator スライス演算子の前後スペース E203 whitespace before ':' しょうがないので ignore しましょう
演算子の改行位置 W503 line break before binary operator x = (aaaaaaaaaaaaaaaaa
+ bbbbbbbbbbbbbbbbbbb) y = (aaaaaaaaaaaaaaaaa + bbbbbbbbbbbbbbbbbbb)
スライス演算子の前後スペース E203 whitespace before ':' black はスライス演算子前後で計算式が入るとスペースを入 れる flake8 は
: にスペースをいれてはいけないと言ってくる この場合の : は演算子ではなくブロック構文の区切りの : のことのはず a = x[start:stop] a = x[start:(start + count)] a = x[start : (start + count)]
フォーマッターを導入していくには 一気に導入 フォーマットのみの PR が嫌でなければ blame したときに困るかも 部分的に導入 なんらかの修正時にフォーマッターをかけていく autopep8
などの設定である内容だけ適用していく フォーマットかけると本来の変更との diff が見づらい
black, isort を CI で使う CI でフォーマットするのではない フォーマット済みであるか確認する check オプションや
diff オプション
テスト unittest nose pytest おすすめ zope.testrunner
pytest テストフレームワーク テストランナー
テストランナーとしての pytest 名前でテストを探し出す discovery 機能 test_* とか Test* とか unittest
で書いたテストでも実行可能 賢いテストレポート 成功したテストの print を表示しない assert が落ちた時、付近の変数の内容を表示してくれる
テストフレームワークとしての pytest fixture まあ好き嫌いはありますが 最近は yield で setup/teadown 相当の処理をそのまま書けます yield_fixture
は deprecated marker 適当にテストを分類したり 特殊な fixture を割り当てたり parametrize もうテストメソッドの中で for 文なんかいらないぞ! 入出力の違いだけのテストならこれでいきましょう parametrize 自体に fixture できないのはちょっと不満
pytest アドオン pytest-cov 基本です。いれておきましょう。 自分が狙ったテストを書けているか確認しましょう coverage に溺れないように! pytest-randomly インストールするだけでテスト順序がシャッフルされます 順序に依存したテストを発見しましょう
ユニットテストを一歩先のステージにもっていきましょう pytest-mock patch デコレータがいくつもある人に patch コンテキストな何段も積み重なってる人に SPY など追加のユーティリティもあるので mock をそのまま 使うよりちょっと便利
デバッグ 使ってないのでわかりません (´・ω・`)
プロファイル profiler gprof2dots profiler の結果を (プロットじゃない方の) グラフ表示にしてく れる
pyinvoke tasks.py 関数に @task デコレータつけるだけ from invoke import task @task
def hello(ctx): print("Hello")
nox テストに特化したタスクランナー tox を invoke にしたようなツール virtualenv と連携
paste script メンテナ不在? そろそろ退役? プロジェクトテンプレートをパッケージングする
cookiecutter github とかで公開リポジトリにするだけ pyramid などの有名プロジェクトも cookiecutter で提供する ようになりました paste script
ほど複雑なことはできない もう複雑なことはやめましょう
設定ファイル ツール独自 .flake8 pytest.ini … setup.cfg tox.ini pyproject.toml
最終公分母は setup.cfg か tox.ini しかたないね black だけ pyproject.toml まあ black
は設定しないって割り切れば… テスト系は tox.ini、それ以外は setup.cfg とか分ける方法も
tox.ini [tool:pytest] test_paths = tests [isort] line_length = 88 multi_line_output
= 3 [flake8] max-line-length = 80 ;W503 line break before binary operator ;E203 whitespace before ':' ignore = W503,E203
こんなにツール入れなくても pycharmでできちゃうよ! って人は CI 上でも pycharm 実行してチェッカーにしてくだ さい
まとめ クオリティチェックは機械にやらせましょう せめて flake8 は標準でいれていてほしいところ フォーマッタはレビュアーのためにいれてあげてください 主義主張は black の前には無意味だ 秘伝のコマンドラインはみんなで使えるようにしましょう
自分のローカルマシンでしか動かない? 環境変数に追い 出せ! エディタは 自主規制により省略されました