Pythonの真の超能力
(youtu.be)PYCON UK 2025でHynek Schlawackが発表した「Pythonの真の超能力」キーノートの要約です。
発表者はプレゼンテーションを始める前に自身の経歴を簡単に紹介し、とくに14年間PyConコミュニティで活動する中で経験した「憎らしい友情」について言及しました。
Python 2から3への移行 (The Python 2 to 3 Migration)
- 背景: Python 3.0は2008年に初めてリリースされ、一般利用のためというより、Pythonの目標を示してフィードバックを得るためのものでした。Python 3.2から利用が推奨されました。
- 主な変更点:
- 文字列処理: Python 3では文字列の基本型が、機械寄りのバイトから人間寄りのUnicodeへと変更されました。
- 暗黙的な挙動の削除: Python 2で可能だった文字列と数値の比較のように、開発者が誤って依存していた多くの暗黙的な挙動が削除されました。これはデバッグしにくいバグの原因になっていました。
- 国際化の改善: Python 2のコードベースはUnicodeデコードエラーにあふれており、Python 3はこれを改善して、より国際化された言語になりました。
- 移行の難しさ:
- コミュニティコスト: エコシステム全体をPython 3へ移植するには莫大なコストがかかりました。移植すべきソフトウェアは多く、当時はテストカバレッジも一般的ではありませんでした。
- 混在コードベース開発: Python 2とPython 3の両方で動くハイブリッドなコードベースをどう書くかについて合意ができたのは、Python 3.3がリリースされた2012年になってからでした。
- 言語モラトリアム: Python 3.0から3.3の間は新機能がほとんど追加されず、開発者がPython 3へ移行する動機に乏しい状態でした。
- 不確実性: Python 3が支配的なバージョンになるかは不透明で、Perl 6のような例のように失敗する可能性もありました。
- Pythonが生き残った理由:
- 新規ユーザー流入: Pythonは、他の言語（Go、Rustなど）が成長していた時期にも、新規ユーザーの流入が離脱を上回っていました。
- 科学・エンジニアリングコミュニティ: 科学者やエンジニアは長年Pythonを使っており、2010年代半ばからはデータサイエンス分野でPythonの人気が急増しました。現在ではPythonユーザーの半数以上が、データ探索や処理にPythonを使っています。
- 既存のエコシステム: NumPyのような強力な科学計算ライブラリエコシステムがすでに存在していました。
- 他のコンパイル言語との相互運用のしやすさ: Pythonは他のコンパイル言語と連携しやすく、C、C++、Fortran、Rustで書かれた高性能コンポーネントをつなぐ「接着剤」の役割を果たせます。
- 探索的プログラミング: Pythonは対話型シェル（REPL）やJupyter Notebookのようなツールを通じて、探索的プログラミングに非常に適しています。
- 漸進性 (Graduality): Pythonはさまざまなレベルの厳密さを提供します。開発者は実験段階では柔軟に作業し、本番段階では型ヒント、リンター、テストなどのツールを使って厳密さを高められます。またJupyter Notebookで始めてWebサービスへ拡張するなど、多様なユースケースにPythonを適用できます。
Pythonの真の超能力: 漸進性 (Graduality)
- Pythonは参入障壁が低いだけでなく、必要に応じて柔軟に使える複数の高い上限も備えています。
- 漸進性の両面:
- 肯定的な側面: ユーザーは望むレベルの厳密さと複雑さを選べます。たとえば、スクリプト作成では型ヒントなしで自由に書き、大規模アプリケーションでは厳格な型チェックを適用できます。
- 否定的な側面: システムに特別なケースや例外を追加すると、短期的には個々のユーザーに利便性をもたらしますが、長期的にはシステム全体の複雑性を増大させます。「簡単であることは、必ずしも単純であることを意味しない」という点が強調されており、これはPythonのパッケージング方式にも表れています。
パッケージング問題の事例 (Packaging Problem Example)
- Pythonアプリケーションを構造化する方法には、「アドホック」方式と「パッケージ」方式があります。パッケージ方式のほうがより明確に定義され、ツールも組み込まれていますが、歴史的な理由からアドホック方式も引き続きサポートされています。
- このため
sys.pathのような問題の理解が難しくなり、pip install --userのような機能はグローバル名前空間で問題を引き起こし、デバッグを困難にします。 - UVのような新しいツールは当初パッケージ方式だけをサポートしていましたが、最終的にはアドホックなプロジェクトもサポートするようになり、複雑性が増しました。
- このような「魅力的な厄介ごと(attractive nuisance)」は短期的な利便性をもたらす一方で、長期的にはコミュニティに大きなコストを生じさせます。
ソフトウェアアーキテクチャ (Software Architecture)
- Pythonコミュニティではソフトウェアアーキテクチャについての議論が不足していると指摘し、その理由として「エンタープライズパターン」への反感や「Java化することへの恐れ」を挙げています。
- 必要性: 複雑なソフトウェアシステムを構築し保守するには、モジュール、レイヤー、相互作用を組織し管理するソフトウェアアーキテクチャについての議論が重要です。
- 解決策:
- Pythonコミュニティは「Pythonic」や「unpythonic」のような言葉で議論を終わらせるのを避けるべきです。
- 他言語コミュニティのベストプラクティス（例: ドメイン駆動設計）を学び、適用すべきです。
- より多くの人がソフトウェアアーキテクチャ関連の知識を共有し、関連コンテンツを作り、解決策に集中する必要があります。
結論 (Conclusion)
- Pythonについて不安がるのではなく、Pythonを書くさまざまな方法を受け入れるべきです。
- 新しいスタイルやツールを試し、考え方を広げるべきです。
- 選択肢にはコストが伴うため、特定の機能がコミュニティ全体に与える影響を慎重に考慮する必要があります。
- 単純なことを簡単にする作業とともに、複雑なことを可能にする作業にもより多くの努力を注ぐべきです。
- ソフトウェアアーキテクチャについてもっと議論し、Pythonをよりよい未来へ導くために独断的な考え方に問いを投げかけるべきです。
このプレゼンテーションはPythonコミュニティの過去・現在・未来をまたぎ、言語の真の強みである「漸進性」を強調するとともに、コミュニティが直面する課題と乗り越えるべき文化的障壁について深い洞察を与えています。
動画を見るには次のリンクを参照してください: https://youtu.be/gDvwRpl9erE
3件のコメント
uvスタイルのモダンなパッケージマネージャーが標準になればかなり便利になりそうですが、やはり難しいでしょうね..
学部の初期にはかろうじて Python 2 のほうがメジャーでしたが、卒業する頃にはみんな Python 3 に移行していたのを覚えています。
コーディングを生業にしている人なら、主にPythonを使っている場合でも、少なくとも1つ以上の他の言語も扱えることがほとんどでしょう。
Pythonはもっと良くなるべきだと言って、他の言語の機能や特徴をやたら取り入れようとするのが理解できません。
そのPythonの足りない部分こそが、Pythonが人気を集めた理由でもあるという点を無視しているように思います。
Pythonはだんだん妙に複雑で扱いにくくなってきています。
Pythonを使う利点がなくなっていくように感じるんですよね。
PythonをJavaのようにしようとするのではなく、必要に応じてJavaを使えばいいだけではないかと思います。
JavaでなければKotlinもあるし、Scalaもあります。
それでもPythonは廃れないと思います。
これほど手軽にコーディングできる言語が、実質的にほかにないですからね。