マジかよ！？知っておくとPythonがもっと楽しくなる、意外と知らない高度なテクニック集
引用元：https://news.ycombinator.com/item?id=43769486
やあ、みんな！ブログの作者だよ！
まさか朝4時に自分の記事がHNのトップページに載ってるなんて思わなかったけど、まあ、そういうことだね！:D
イントロにも書いたけど、これはブログを始める1ヶ月前に書いた14個の短いツイートが元になってるんだ。ブログを立ち上げた時、「Pythonのナイスなテクニックを2週間かけて書いたんだから、最初の楽しい投稿として再利用してもいいんじゃない？」って思ったんだ。
だから流れがちょっと変に感じるかもしれない（プロキシプロパティはPythonの「機能」そのものではないっていう人もいるように）。その日クールだと思ったものを載せてただけなんだ。金曜日ならちょっとマニアックなもの、月曜日なら役立つものを探してたんだよね。シリーズ全体を改善してたのも理由の一つ。
タイトルも同じ。Pythonを仕事や趣味で書いてて面白いと思った14個の機能なんだ。高度じゃないって人もいるけど、まあそうだね！タイトルは5秒くらいで決めたんだ。
このテクニックは、多くの仕事で見たことのあるコードよりも高度だよ！初心者向けのコンテンツと、コアデベロッパーが書くようなニッチなコンテンツの中間にあるのがいいね。
記事、すごく面白かったよ。要点がまとまってて、リストも充実してるし、例も分かりやすい。Pythonを20年書いてるけど、最近はこんなに面白い記事はなかなかないよ。すごいね。
ブログに記事の背景がよく説明されてると思うよ。
でも、アイデアから投稿まで毎日やってたって聞いて驚いた。実行する前に1週間くらい準備すると思ってた。
いずれにしても、素晴らしい記事だよ。typingが多いとか、新しい機能が多すぎるとか、ニッチな解決策でコードを短くするのが好きとか、どう思っててもね。
すごく良いね。ほとんどのPython開発者が何かを学べると思うよ。Pythonはすごく変わったね。あなたの例を見る限り、良くなってると思うよ。
記事を書いてくれてありがとう。楽しく読ませてもらったよ。
トップページに載ってよかったね！（サーバーは大丈夫かな？）
Pythonを15年書いてるけど、結構知らないことが多かったから、個人的にはかなり高度だと思うな。
getterとsetterがないのが残念！
Pythonを使うたびに、ロジックを作る上でのガードレールの少なさに惹かれる反面、自分のコードがPythonを使いこなせてない人のコードに見えるんじゃないかって不安になるんだよね。慣習や緩いルールが多いから。こういう記事を読むと、Pythonの奥深さに驚かされるし、変化の大きさに驚かされる。Goみたいに、数年後にdeprecatedになったり、時代遅れになったりしない安心感はないけど、知らないことがたくさんあるって分かってよかったよ。
Pythonには、自分でガードレールを再利用したり、構築したりできる機能がたくさんあるよ。
truthinessとfalsinessの概念はなくなってほしいけどね。あれのせいで嫌なバグがたくさん発生したし、数文字削れるだけだから、割に合わないよ。
truthinessとfalsinessはよく使う機能の一つだよ。if not collectionはほとんどすべてのプロジェクトで何度も出てくる。
マジでみんな使ってるよね。それがバグの原因になったりするんだよなー。例えばさ、ユーザーがテキストボックスに0を入れた時、プログラムが0を入れられた時と同じ反応をするんじゃなくて、値が何も入力されなかった時と同じ反応をしちゃうみたいな。
そうなるとシステムが想定外の動きをし始めてみんなパニックになるんだよね。
Pythonで長くプログラミングしてるといつか遭遇するよ。最初は気づきにくいかもね。
昔、Pythonのバグトラッカーに「if time_variable:」って書いて、真夜中に呼ばれた時だけfalseになるって人がいたんだよね。最初は対応しないってことになったらしいよ。
(真夜中がdatetimeの空文字列、0、空リストとかと同じ扱いだったんだって)
よくあるのは、JSONから来た文字列の値に対して、Noneかどうかをif not sでチェックする時に、空文字列もfalseになるってことに気づかないパターンだよね。
マジかよ、この前書いたコードがバグってるかも。こういうクソ仕様があるからJSは避けてるんだよね。本当に最悪な便利機能だよ。
驚くような挙動なしにコードをコンパクトに、かつ読みやすく保つために、単項の”truthy”演算子が必要だわ。
”truthy”演算子はbool()だよ。問題は空文字列がfalsyなこと。
個人的には、こういうテストのパターンに落ち着いた:
# Noneのチェック
if x is not None: …
# 空文字列のチェック
if x != ””: …
# 文字列以外の空コレクションのチェック
if not len(x): …
最後のケースでは、0がfalsyであることを利用して、長さが特定の値と等しいかどうかをチェックするのとは区別してる。だから後でコードを読んでて”not len”って見たら、それが空チェックだってすぐわかるようにね。
もちろん、これは一貫してやってる場合に限るけど。言語がそれを強制しないし、Pythonの標準もないから、まだ危険は残るよね…
それってruffとかのチェッカーに追加して、頭ごなしに注意されるような、偏ったルールって感じがするな。ruffのカタログには、俺のミスを見つけるのに役立つtruthinessに関する意見がたくさんあるよ。
bool( thing )は冗長すぎる。単項演算子があると嬉しい。
問題は空文字列がfalsyであることそのものではないと思う(個人的な好みじゃないかもしれないけど)。むしろ、暗黙的なboolへの型変換が問題だと思うんだよね。だから単項演算子が欲しい。
これは、暗黙的な型変換が悪いことの例として、また1つ追加されると思うよ。
＞I don’t think the problem is that empty strings are falsy per say (although that might not be to your personal preference).
訂正させて。問題はfalsyであることそのものではなく、それがあまりにも多くの無関係なものとこの特性を共有していることだ。そして、これが動的型付けと組み合わさることで、与えられたxがそれらのどれにでもなり得る。
特にNone/‘‘は、Pythonで値の欠如を報告する標準的な方法なので、非常に一般的。
そのようなチェックのための記号的な単項演算子を持つことについては、Python構文の全体的な雰囲気に反すると思う。つまり、”not”のようなものを明示的に書かなければならない言語だし、len()もLuaとは違って関数だ。このための最もPythonicなインターフェースは、記述的な名前を持つインスタンスプロパティとして提供することだと思う。
マジかー、Pythonって機能が少なすぎてイライラするんだよね。コード書く量が増えるし、便利さもイマイチだし。AI補完がないとやってけないわ。古いコードと新しいコードが同じに見えるのは、言語が進歩してないからじゃん？Goは構造的型付けとジェネリクスをサポートしてるから、Goばっかり書いちゃうんだよね。Goだと循環インポートができないから、リファクタリングが必要になるのが面倒。Pythonは循環インポート推奨してないけど、回避策はいくらでもあるから楽だよ。TypeScriptのimport typeが欲しいなー。Pythonは言語の設計に縛られずに済むから気が楽なんだよね。
Pythonらしい書き方を勉強すれば、もっと楽しくなるよ。C++とかRust、JavaScriptみたいな書き方してる人が多いけど、それだとPythonの良さが活かせないんだよね。Pythonistaのやり方を参考にすれば、もっとPythonが好きになると思うよ。
PythonはPythonらしく、Golang、Rust、TypeScriptはそれぞれの哲学とデザインで良いと思うなー。全部コード書くけど、最近のPythonにはちょっと不満があるんだよね。Pythonが人気になったのは、型チェックとかアノテーションのせいじゃないと思うし。なんか他の言語みたいになってきてる気がする。少数派なのはわかってるけど、たまにはこういう意見も言いたくなるんだよね。でも、最近の機能がまとまってて良い記事だったよ。SOの古い記事も参考になるかもね。 型チェックとかアノテーションは、Pythonが人気になった理由じゃないけど、あっても困らないよね。気軽に書くスクリプトに使う必要はないと思うけど、ライブラリ作ったり、大規模なコードベースをメンテするなら便利だよ。Pythonの内部でも使われてるし、多くの開発者は当たり前だと思ってるんじゃないかな。例えば、python-opencvは型がないから、マジで使いにくいんだよね。あと、SOのスレッド紹介してくれてありがとう！ ＞Pythonが人気になったのは、型チェックとかアノテーションのせいじゃない。“ 良い記事だった。でも、新しい機能が増えすぎて、コードの意図がわかりにくくなってる気がするんだよね。IDEがないと、何が起きてるのか理解するのが難しい。どんどん複雑になってる感じ。新しい機能は便利だけど、PythonのZenに反してる部分もあると思う。シンプルでわかりやすく、効果的で実用的っていうPythonの良さが薄れてる気がする。 Pythonはずっとglue scriptとかbuildとかテストに使ってて最高だと思ってた。でも、大規模アプリには向かないと思ってたんだよね。動的なせいでバグが出やすくて、規模が大きくなると手に負えなくなる。型システムが入ってからは、考えが変わったよ。今は大規模なtooling codebaseがあるけど、型チェックのおかげでメンテしやすくなった。 Guidoのバランス感覚は素晴らしいよね。型チェックとかアノテーションは使いたくなければ使わなくてもいいし。複雑なシステムで遊ぶときは便利だけど、完全にoptional。 教えてほしいんだけど、Pythonは動的型付けでmonkey patchし放題な言語で、型ヒントは完全に任意で使えるってことだよね？ハックし放題でmonkey patchも自由。Rustのborrow checkerもないし、型チェッカーも不要。アヒルさんだらけ。必須の機能とか、互換性のない変更はないよね？一体何が不満なの？ 完全にoptionalだよね。glue言語として使うとしても、typing annotationsを全く書かなくても、使うライブラリに型があればすごく便利だよ。build stepも増えないし、マジでfree。 良いリストだね。知らなかったか、長年使っててみんな知ってると思ってたかって感じだよね。いくつか追加するよ。 ＞ did you know init.py is optional nowadays? ＞ did you know init.py is optional nowadays? 良い指摘だね！他に何か、みんなが知らないかもしれないと思うことはある？ これは”知らなかったこと”の素晴らしいリストで、自分のツールキットに追加するために目を通す価値があるよ。 +1 to itertools特にね。めっちゃ強力だし、ドキュメントページの最後にあるレシピは最高だよ。 ＞ The only problem I’ve found is that for interviews, people often aren’t familiar with it, which can lead to you solving whatever puzzle they had in far less time than they intended, and without manually building whatever logic it was they assumed you would need. ＞I didn’t get the job. Pythonの一番のメリットは、まるで実行可能な疑似コードみたいに感じられることだよね。言語が邪魔せずに、やりたいことに集中できる。だからプログラミング初心者でもPythonは使いやすいんだと思う。色々便利な機能が増えるのはいいけど、複雑になると魅力が薄れちゃう気がするな。確かに便利だけど、使いこなせる人ってそんなに多くないんじゃないかな。 それは違うんじゃないかな。「便利な機能」が増えても、元々の魅力がなくなるわけじゃないじゃん。自分でも言ってる通り、知らない機能は判断材料にならないし。もし知って嫌いなら、今まで通りに使えばいいだけだと思うけど。 ＞もし知って嫌いなら、今まで通りに使えばいいだけだと思うけど。 Luaも同じような感じで、もっとシンプルなんだよね。コミュニティの多くはLua5.1を使い続けてるから、「進化」の心配も少ないし。もちろん、Luaは必要なものが全部入ってるわけじゃないから、外部ライブラリの「進化」問題はあるかもしれないけど、Penlightみたいなのはほとんど変わらないけどね。 コレクションのabcコンテナを型アノテーションに含めたり、TypedDictで構造化された辞書を扱いやすくしたり、Counterの存在を毎回忘れてしまうのが嫌だなって思うくらいかな。walrus operatorを嫌う人もいるけど、良い使い道を見つけるまでは自分も嫌いだったんだよね。最近は厳密に型付けされたPythonを書くことが多いんだけど（これも最初は嫌いだった）、walrus operatorを使うとコードがすごくスッキリするんだよね。Optionals（もしくはNoneとのUnion）を扱うときに便利で、正規表現パターンを使うときによく使うよ。例えば「if (match := pattern.search(line)) is not None: print(match.group())」みたいな感じ。matchを条件式の前に書いてもいいけど、こっちの方がmatchの有効範囲が条件式の中だけだってことが分かりやすくて、他の場所で再利用しようとする誘惑が減るんだよね。あと、Pythonの機能じゃないけど、正規表現パターンで名前付きキャプチャグループをもっと使うようにしてほしいな。「.group(“prefix”)」の方が「.group(1)」よりずっと読みやすいし。 9.3のショートサーキット評価についてだけど、空文字列がある場合は評価が違うよね。if-else文は空文字列を有効な値として扱うけど、or演算子はNoneと同じように扱うよ。 9.2についても同様で、walrus operatorを使った代入は、値が0（またはfalsyな値）の場合に失敗するよ。 メタクラス以外のほとんどの機能は、高度な機能じゃないと思うな。シンプルだけど、あまり知られていないか、使われていない機能って感じ。メタクラスは複雑で、自分は避けてるよ。あと、「Proxy Properties」は機能というより、dunderメソッドの特定の使い方だよね。 シンプルだからって、基礎レベルとか初心者向けってわけじゃないんだよね。 Javascript/TypescriptからPythonに転職してきた身としては、これはめっちゃ役に立つリソースだわ。いくつかポイントを紹介するね。 全角の＞5. Protocols：Typescript使いとしては、めっちゃ親近感わくけど、Pythonっぽくない。複雑な気持ち。” そうかもね。Python初心者だから、何がPythonicなのか直感的に分からないんだよね（PEPsを一日中読んでるだけじゃ）。今の型システムを使ってると、nominative typesとstructural typesが共存してるのがちょっと違和感あるんだよね。 これマジすごいし、知らなかったわ。 *を使えば逆もできるよ（これ以降の全てのパラメータはkeyword-onlyにする必要がある）。 この機能、普段から使ってるしオススメだよ。例えば、boolean flagsを関数に渡すときに、名前で渡すようにすることで、call-siteでの意味を明確にできる。 TFAのfor/elseのユースケースは納得できないな。 これだとどう？ うん、それの方が良い例かもね。 チームが関数型プログラミングの概念に慣れてるなら、これの方が良くない？ for/elseのメリットは可読性と書きやすさだと思うな。何もかも最初に準備する必要がないし。（デメリットは、基本構文に余計なものが増えることだけどね。） こういう検索処理はいろんな方法でできるから、抽象化する価値あるよね。例えばこんな感じ。 確かに。デフォルト値がいらないケースも考えて複雑にしすぎちゃったけど、もっと簡単にできたね。 やったー、first()がmore_itertoolsに入ってる！ forループのelse句は良いよね。でも、ほとんどの人が知らないし、キーワードの それもやっぱり紛らわしいんだよねー。 記事面白かったよー。Pythonの専門家ってわけじゃないんだけど、ほとんどの機能ってtypingモジュールの機能じゃん？特にGenericsとかProtocolsは、duck typingで良くね？って思っちゃった…。最近のproduction-levelなPythonコードって、型をめっちゃ使うの？duck typingってダサいの？ Structural typingは、dynamic duck typingのstatic版みたいなもん。type checkerと相性が良いんだよね。記事に出てきたProtocolsは、inheritanceなしで使えるし。duckはSupportsQuack protocolの存在を知らなくても良いんだよ。quackって鳴けば、type checkを通るんだから。 ＞最近のproduction-levelなPythonコードって、型をめっちゃ使うの？ MLの分野で仕事してるから、Python嫌いになれないんだよねー。でも、type system（3.12以前のやつね）にはマジで苦労させられたわ。3.12以降で、全てのlibraryが使えるようになるのが待ち遠しい。その経験から、TypeScriptのtype systemのありがたみが分かったわ。まさかそんなこと言う日が来るとは思わなかった。 マジでイライラしたバグは、memory mapped CSC format sparse arraysを使ってたとき。arrayのindexをint64にしたかったから、初期化の時にそう指定したんだよね。でも、downstreamsの処理で、indexの値をみて、精度が落ちないと思ったらint32に動的にcastしちゃうんだよ。それがCで実装されたmoduleとのroundtripを完全にぶっ壊すんだよね。intermittentなbugだったから、マジで地獄だったわ。 おーい、坊や…もっとヤバいの試したことある？マジでぶっ飛ぶやつがあるんだけど。ハマっちゃうぞ。 10年試しても、dependent typesがないじゃん。Idrisを受け入れようぜ。 それな。自分でも中毒だってわかってるし。 わかる～。Pythonのtyping、TypeScriptと比べてマジで使いにくい。3.12以降でもね。Mypyの推論がアホすぎて Mypyは段階的な導入を想定して設計されたんだよ。 astralの人たち（uv、ruff）のtype checkerが出るのを待ってる。Mypyは大規模プロジェクトだと不安定で遅いことが多いんだよね。 pyright/pylance/basedpyrightをチェックしてみて。全体的に優秀なtype checkerだよ。TypeScriptの”unknown”もあるし（ちょっと違うけど）。 dataclassみたいなものに対する特別なケースがまだあるんだね。Pythonの型チェック（Red Knotは試してないけど）で、TypeScriptのZod schema validationみたいな半ば魔法みたいなことができるとは思えないな。 マジそれ。PythonのtypingはTSに遠く及ばない。例に出てる件がそれを物語ってるよね。OPの具体的な懸念が(一部)pyrightで解消されるから言及した。 0はfloatにもなり得るから、numbers型にするのが妥当じゃない？ 試してみて：もっとコメントを表示（1）
Pythonが普及したのは、PHPと同じで、どこでも使えるし、初心者でもすぐにアプリが作れるからだよ。でも、新卒のエンジニアが作るプロトタイプに必要な機能と、100人のチームで開発するのに必要な機能は違うよね。Pythonは、大規模なバックエンドアプリから、Jupyterでデータ分析する人、デプロイメントスクリプトを書く人まで、いろんな人が使ってる。ちょっとしたスクリプトなら型チェックは不要だけど、大規模アプリなら使った方が良いに決まってる。
* init.pyって最近は必須じゃないって知ってた？
* relative importsは”from ..other import foo”みたいにできるよ
* 3.13から@deprecated decoratorがあるよ。想像通りの動きをするよ
* 新しいジェネリクスの構文はメソッドや関数でも使えるよ。”def methodT”めっちゃクール
* typeddictsでkwargsをタイプヒントしてアンパックできるよ。”def fn(kwargs: Unpack[MyKwargs])”
dataclassesとかpydanticはimmutable objectsをサポートしてるよ。”class MyModel(BaseModel, frozen=True)”とか”@dataclass(frozen=True)”でできる
* dataclassesとかのclass attributesは”MY_STATIC: ClassVar[int] = 42”で定義できるよ。これはabstract base classes(ABC)もサポートしてるよ
* TypeVarはsubtypeを強制するためのbindingをサポートしてるよ。”TypeVar[’T’, bound=X]”。3.13からはdefaultも指定できるよ。”TypeVar[’T’, bound=X, default=int]”
* @overloadは特にget()メソッドで、defaultがNoneじゃないならNoneを返さないってことを表現するのに便利
* Union[a, b]とかOptional[a]の代わりに”a | b”とか”a | None”って書けるようになったよ
* matchではassert_never()を使って、”case _:”ブロックで網羅的なマッチングを保証できるよ
* typingはreveal_type()を持ってて、mypyに型の推論結果を表示させられるよ
* typingの”Self”を使うと、クラスメソッドの戻り値の型をより適切にアノテートできるよ
* time packageはmonotonic clocksとか、time()以外の関数も持ってるよ
他に何か知ってる人いる？
＞”init.pyがなくても動くのは知ってる？”
影響はあるし、たいてい含める価値はあるよ。前は省略してたけど、今はデフォルトで含めるようにしてる。それに、”最近”って言うけど、もう13年くらい前だよ(https://peps.python.org/pep-0420/)。
＞ since 3.13 there is a @deprecated decorator that does what you think it does
＞”3.13から@deprecated decoratorがあるって知ってた？”
良い発見だね。warnings standard libraryから来てるってことも言及する価値があるかも。
＞ the time package has functions for monotonic clocks and others not just time()
＞”time packageにはmonotonic clocksとか、time()以外の関数があるよ”
色々あるけど、どれくらいの人が必要としてるかは疑問だな。
それにしても、他の人がこういうリストを作ると、type annotationsのトリッキーな話がすごく多いのがいつも不思議。typing standard libraryが導入された時、その機能に懐疑的だったんだ。人々がそれがなぜか必要だと言い続けても、ますます警戒するようになったよ。
＞”init.pyって最近は必須じゃないって知ってた？”
必須じゃないってわけじゃないよ。省略するとnamespace packageになるけど、たぶんそれは望んでないよね。
＞ TypeVar supports binding to enforce subtypes: “TypeVar[’T’, bound=X]”
＞”TypeVarはsubtypeを強制するためのbindingをサポートしてるよ。”TypeVar[’T’, bound=X]””
新しいジェネリクスの構文を使うとこうできるよ。
def methodT: X
もし本当に”advanced Python”に興味があるなら、Ramalhoの”Fluent Python”を勧めるよ。私は第一版を持ってるけど、async bitsも含めて、まだとても参考になるよ(coroutinesをasync syntaxに翻訳するだけ)。第二版はもっと新しいよ。
それから、standard libraryのfunctools[0]とitertools[1]モジュールもチェックするのを勧めるよ。docsを上から下まで読むだけでいいんだ。
それから、Python Data Model[2]の最初のいくつかのセクションを読んで、このページをブックマークしておくのも価値があるよ。
[0] https://docs.python.org/3/library/functools.html
[1] https://docs.python.org/3/library/itertools.html
[2] https://docs.python.org/3/reference/datamodel.html
唯一の問題は、面接で、みんながitertoolsに慣れてないことが多いってこと。だから、彼らが想定してたよりもずっと短い時間でパズルを解いてしまって、彼らが想定してたロジックを手動で構築する必要がなくなっちゃうことがあるんだよね。
＞”面接でitertoolsを使うと、想定より早く問題を解いてしまい、手動でロジックを組む必要がなくなることがある”
似たようなことが起きた私の好きな例は、数字の桁を反転させるように頼まれた時。ちょっと冗談めかして、10進数を想定してるかどうか尋ねたら、なんか変な顔をされたから、何かあるんだなってわかった。彼らは私の””.join(reversed(str(123456789)))”って答えに全く感銘を受けてなかったよ。私は仕事を得られなかった。
＞”仕事を得られなかった。”
彼らの損失だね。算術的な解決策が必要だと期待するのは、Pythonのオーバーヘッドを受け入れるのと矛盾してるよ。もし私が覚えてる限りでは、あなたのアプローチは実際にはより速いはず。文字列変換は暗黙的にベアメタルでnumber-crunchesするけど、Pythonコードでの算術的なアプローチはそうじゃないからね。
彼らがその後intに変換することを望んでた場合を除いて。あるいは、スライシングトリックで文字列を反転させることを望んでいた場合（これは確かに、さらに少し速い）。
それって、他の人が書いたコードに「便利な機能」が使われてたら成り立たないよね。もっとコメントを表示（2）
1. Typing overloads：TSにはtyped overloadsがあるけど、Javascriptの残念な機能のせいだと思う。経験上、これはアンチパターンか、せいぜいcode smell。使うならtech debtとして扱った方がいいかも。
2. Keyword-only and Positional-only Arguments：これは1つ目の機能と逆で、メソッドのシグネチャを厳密にする機能だけど、構文が難解すぎる。どこでも使いたいけど、可読性が心配。
3. Future Annotations：このセクション、マジ感謝。forward referencesでずっと苦労してたから。PEP 649に期待。
4. Generics：レガシーな3.10 codebaseで泣いてる。
5. Protocols：Typescript使いとしては、めっちゃ親近感わくけど、Pythonっぽくない。複雑な気持ち。
14. Metaclasses：
全角の＞もし君が1%の選ばれし者で、metaclassesしか解決できない問題を抱えているなら、これはPythonオブジェクトシステムの内部をいじれる強力なツールだ。
全角の＞または、自分の問題は特別だと思い込んで、単純な問題に魔法のようなオーバーエンジニアリングな解決策を適用するのが大好きなdevは、次に君のコードを継承する人を困らせるだろうね。codepathsを追跡するのがマジで大変になるからな。
いやいや、めっちゃPythonicじゃない？Pythonで最初に学ぶことの一つは「すべてはduck typed」ってことだけど、型システムは主にnominative typedじゃん。Protocolsは最初からあるべきだったと思うな、Typescriptのinterfacesみたいに。
https://blog.edward-li.com/tech/advanced-python-features/#2-…
def bar(a, /, b):
…
# == ALLOWED ==
bar(1, 2) # All positional
bar(1, b=2) # Half positional, half keyword
# == NOT ALLOWED ==
bar(a=1, b=2) # Cannot use keyword for positional-only parameter
https://docs.python.org/3.12/reference/compound_stmts.html#f…
for server in servers:
if server.check_availability():
primary_server = server
break
else:
primary_server = backup_server
deploy_application(primary_server)
こうする方が短くない？
primary_server = backup_server
for server in servers:
if server.check_availability():
primary_server = server
break
deploy_application(primary_server)
for server in servers:
if server.check_availability():
primary_server = server
break
else:
logger.warning(“Cannot find a valid server”) <—
primary_server = backup_server
deploy_application(primary_server)
available_servers = (server for server in servers if server.check_availability())
primary_server = next(available_servers, backup_server)
deploy_application(primary_server)
こっちの方が読みやすいと思うんだよね（何をするかに注目できる）。
＞def first(candidates, predicate, default):
＞ try:
＞ return next(c for c in candidates if predicate(c))
＞ except StopIteration:
＞ return default
＞deploy_application(first(servers, Server.check_availability, backup_server))StopIteration例外をキャッチする代わりに、nextにデフォルト値を指定すればOK。
next((c for c in candidates if predicate(c)), default)もっとコメントを表示（3）
more_itertoolsはPythonの標準ライブラリに入っててほしいものリストの常連だよね。（削りたいものリストの方がもっと長いけど。それは主に美学的な理由で、メンテの負担が大きいわけじゃないと思うけど。）
それなのに、必要な時に限って忘れちゃうんだよなぁ。else:がマジで紛らわしいんだよなー。いつも「no break:」って覚えちゃうわ。elseがbreakに意味的にくっついてるのに、構文的にはループの本体にくっついてるのが問題なんだよ。それだと、ループの中身が実行されなかったときに実行されるみたいに見えちゃうじゃん？
俺的には、ループの最後に必ず実行されるブロックがある方が良いと思うんだよねー。キーワードはfinallyで、breakがあったかどうかを示すbooleanフラグを渡すとか。
もっと良いのは、breakに引数を渡せるようにして、それをfinallyで受け取れるようにするとか。そしたらこんな風に書けるじゃん？
会社の中のコードは知らんけど、最近のopen source projectはtyping使ってるのが多い気がする。昔のprojectもtypingに移行してたりするし。
＞duck typingってダサいの？
そんなことないよ。Protocolsを使えば、duckにどんな形を期待するか定義できるし。abstract classesを使うかprotocolsを使うか、みたいな議論はあるけどね。
タイプにハマってることに気づいてないんだな？
光の方へおいで - Haskell!
もしくは、logic + functional programming: Curryを受け入れよう。https://curry-language.org/i: int = 0みたいに書かないといけないし。TypedDictも最初は期待したけど、結局castしまくりになる悪夢。TypeScriptのunknownが恋しい。def f(i=0)みたいに、iがfloatとかcomplexとかnumpyとか、どんな数値型でもあり得るPythonコードはたくさんあるし。これはダックタイピングって言うんだけど、型チェッカーがi: intって決めつけるのは良くないよね。Pyrightは新規プロジェクトか、既存プロジェクトを”修正”するのに時間をかければうまくいくかも。でも全然違うツールだし、Mypyのuse caseを理解せずに批判するのはナンセンス。def f(i=0)でiがnumber-likeな型になってくれたら嬉しいんだけど、現状は全く型付けされないんだよね。MypyはAny型だと”推論”しちゃう。Pyrightも試したけど、おっしゃる通り既存プロジェクトだと”修正”にめっちゃ時間かかる。
def f(i=0) -> None:
reveal_type(i)
推論される型はfloatでもintでもなくAnyだよ。Mypyは平気でf(“some string”)を許しちゃう。
