参加してきました。
1回来ないと随分久しぶりな気がしますね。
あいにくの雨でしたが楽しんでこれました。
当日の様子は@lincolinnyanさんがまとめてくれています。
エキスパートPythonプログラミング読書会 第二期 06 - Togetter
全体としてはサクサクテンポよく進んでいました。
テーマが「良い名前を選ぶ」で、
コードがあまりでてこなかったからかもしれませんね。
流れとしては以下のとおり。
毎度おなじみアイスブレイク。
今回も各島ごとに行いました。
自分以外の方は皆さんアプリや自社サービスを行なっている方々ばかり。
@tfmagicianさんがPyramidについて熱弁されてました。
特に気になった点をいくつか。
- PEP8…命名規則。コーディングルールについてまとめたもの。
日本語訳はこちら
PEP 8 - - Style Guide for Python Code
ex)
デリミタで揃える
トップレベルの関数のクラス定義の間は、２行あける
演算子の前後にスペースを１つ入れる
チェックツール:PEP8, pyflakes
小話:Googleは昔インデントスペース２だったのが、４に変わったらしい。
- パブリック変数とプライベート変数
Rubyだとよく使うメソッドは名前を短く,
あまり使わないものは名前を長くする慣習があるらしい。
Pythonの場合は短くするよりも意図をわかりやすく表現するほうが大切。
- プライベート変数を保護する仕組みはPythonにはない。
それっぽいものはあるがプライベートメソッド,フィールドは存在しない。
複雑になるから。Pythonは元々クラスの概念がなかった。
クラスの概念を導入する段階で付けなかった。
継承してプライベートと扱うのはメリットがなかったと考えられる。
- 特殊メソッドは継承、マンダリングされません。
- importする時にallや*はなるべく書かないようにしましょう。
- 引数のベストプラクティス
引数は少しずつ作ろう。必要なものだけ追加していこう。
引数とテストを信頼しよう。つまり「テスト書こう。」
*argsと**kwには注意。本当に着ているか確認するのに、
if文をたくさん書かないといけなくなる。
→フレームワークを作る時や、デコレータを実装する時、
メタプログラミングなどはどうしても必要になってくのだけど、
気をつけて使おう。
- パッケージ名をつけるのは難しい。
グランドルールはPEP8として、ローカルルールでわかりやすくするなど、
読みにくくなる場合はPEP8を破ってもいいのではないか。
- pylintやPEP8とかは今だとCIと組み合わせて
自動レポートとかうまくできるようになる。
- docstring, testcode, 使い方を書くと実装の構成の方にフィードバックを
かける時にテストとしてはやりやすくなる。それを反復し、実装に
反映させていく。
- Pythonのインタプリタから
import antigravityって打つと、デフォルトのブラウザから
xkcd: Pythonが見れる。
@takanoryさんの「PyCon台湾行くよ！壁Py宣伝してくるよ！」
@shiumachiさんの「Hadoop documentの更新日時検索作りました
(←名前が思い出せない)」
@aodagさんの「フレームワークなしでWSGIプログラミング」からのbuchoパッケージ紹介
でした。
来月とか参加できるかな……
参加できなくても学習は続けていきたいですね。
