ハクソク

世界を動かす技術を、日本語で。

Pythonに切り替えて、実際に楽しんでいます

2025年7月16日原文(cesarsotovalero.net)

概要

  • Python を本格的に使い始めた理由と、その魅力の再発見。
  • AI開発 や「現場投入」レベルのPythonアプリ構築で感じたギャップ。
  • プロジェクト構成 や推奨ツール・ライブラリの紹介。
  • 実践的な設定例 やワークフローの共有。
  • 個人の経験に基づく 強い主観を含む内容。

Pythonを本気で使い始めた理由と進化の実感

  • AIブーム による巨大なビジネスチャンスの到来。
  • AI分野のデファクト言語 としてのPythonの地位。
  • 以前は 小規模なスクリプト作成 用途が主だったが、AIアプリ開発を機に本格利用。
  • VSCodeとの親和性 や、Unix系OSへの標準搭載による利便性。
  • Pythonエコシステムの進化 （ライブラリ・ツールの充実、速度向上、モダンな文法）。
    • 例：Cythonによる高速化、__init__などのレガシー要素の隠蔽。

プロダクション用途とスクリプト用途のギャップ

  • Jupyter Notebookや簡易スクリプト と 本番運用アプリ の間に大きな差。
  • 本番向け開発 に必要なツール・構成・ワークフローの重要性。

プロジェクト構成の好みと理由

  • モノレポ （フロントエンド＋バックエンドを単一リポジトリで管理）推奨。
    • 複数リポジトリは検索性や管理性が悪化。
    • 一人開発なら分割は不要、シンプルさ重視。
  • プロジェクト自動生成ツール の理想像を模索中（CCDSはDS向けでフルスタックにはやや不向き）。
  • 典型的なプロジェクト構成例：
    • .github/：GitHub ActionsやDependabot設定
    • .vscode/：VSCode用設定
    • docs/：ドキュメント（MkDocs利用）
    • project-api/：バックエンドAPI（FastAPI等）
    • data/：データセットや静的ファイル
    • notebooks/：Jupyterノートブック
    • tools/：開発・デプロイ用スクリプト
    • src/app/：アプリ本体
    • src/tests/：テストコード
    • project-ui/：フロントエンド（Next.js, React等）
    • 各種設定ファイル（Dockerfile, Makefile, pyproject.toml, .gitignore, .pre-commit-config.yaml など）
  • 命名規則 は短く・ハイフン区切り、snake_caseは避ける。
  • フロントエンドとバックエンドは責務分離、重い処理はAPIサーバー側へ。

Pythonツールボックス

  • uv ：高速なパッケージ管理＆ビルドツール
    • 依存関係管理・仮想環境作成・インストール・ビルドを一元化
    • 主要コマンド例：uv init, uv add, uv sync, uv venv activate
    • 重要ファイル：pyproject.toml
  • ruff ：超高速リンター＆フォーマッター
    • isort, flake8, autoflakeなどを統合
    • PEP8準拠
  • ty ：静的型チェックツール
    • typingモジュールと組み合わせて型安全性向上
    • Astral製（uv, ruffも同社製）
  • pytest ：標準的なテストフレームワーク
    • シンプルなテスト記述・豊富なプラグイン
    • テスト実行例：uv run pytest
  • Pydantic ：データ検証＆設定管理
    • 環境変数や.envから設定を自動読み込み・型検証
    • 例：BaseSettings継承クラスで設定管理
  • MkDocs ：静的ドキュメントサイト生成
    • OSSプロジェクトのデザインを流用しやすい
  • FastAPI ：高速API構築フレームワーク
    • Starlette, Pydanticベースでパフォーマンス・型安全性に優れる
  • dataclasses ：データ格納用クラスの簡易定義
    • __init__や__repr__などの自動生成でボイラープレート削減

バージョン管理とCI/CD

  • GitHub Actions ：CI/CDパイプライン自動化
    • OSごとのテスト・ビルドを簡単に設定
    • 例：Dockerコンテナ内でpytest実行
  • Dependabot ：依存パッケージの自動アップデート
    • .github/dependabot.ymlで設定
  • Gitleaks ：機密情報のコミット防止
    • APIキーやパスワード漏洩対策
  • pre-commit ：コミット前フックで静的解析や整形を自動実行
    • ruffやgitleaksとの組み合わせ推奨

まとめとコメント募集

  • 紹介したツール・構成は筆者の主観が強い が、実際の開発で役立ったものばかり。
  • 他におすすめのツールや工夫があれば、ぜひコメントで共有してほしい。

Hackerたちの意見

Pythonは、__init__や__new__などのレガシーな醜さをうまく隠して、良いセンスを持つ開発者に合わせて文法を柔らかくしている。__init__や__new__の何が問題なの？ @dataclassはとても素敵な構文糖だけど、初期化子やアロケーター、コンストラクタのダンダーメソッドにアクセスできることが「レガシーな醜さ」だと主張しているの？ これは、Pythonicなビルトインを意識したPythonの核心だよ。奇妙だね。

└

奇妙なのは、それを醜いと考えないことだね。Kotlin: コンストラクタはクラス定義の一部か、キーワードのコンストラクタ。Ruby: initialize JS: constructor Python: new, init まさにこのミームだよ: https://knowyourmeme.com/memes/three-headed-dragon

└

おそらく、普通の識別子に特別な意味を持たせるシステムのことだね。__はPythonの予約語でもなんでもない。でも、メソッドや属性の名前を付けるときに従うべき一連の慣習があって、それが明らかに人工的なんだ。言語定義の特別な部分を言語構文の特別な部分にする方が、他の似ていないものと区別なく扱うよりもクリーンだと思う。C++では、クラスにバイナリの+演算子を定義したい場合、特別な名前operator+を持つメソッドを与える。Pythonでは、同じことをするために、擬似特別名__add__を持つメソッドを与える。Pythonのやり方が悪いとは思わない？

└

__init__や__new__の何が問題なの？ @dataclassはとても素敵な構文糖だけど、初期化子やアロケーター、コンストラクタのダンダーメソッドにアクセスできることが「レガシーな醜さ」だと主張しているの？ 私の読みでは、「醜さ」はメソッド名、特にダブルアンダースコアにあって、メソッド自体の可用性ではないと思った。

└

もう10年くらいプロでPythonやってるけど（バックエンドのウェブ開発やファイル処理）、著者がダンダーメソッドを「レガシー」と表現したのはあまり好きじゃないな。でも、C#のバックグラウンドからすると、あんまり使うことはないんだよね。著者はJavaについてのブログも書いてるけど、C#とそんなに違わないから、もしかしたらそのせいかも。コードの「大局」を考えるようになれば、ダンダーも取り入れるようになるかもしれないけど、それまでは…

誰かがPythonを好きになれることを発見してくれて嬉しいよ。プロジェクトのためにRubyを提案してたのに、顧客がPythonを強く希望したから、仕方なく学ぶことになったんだ。何年も前の話で、その頃はRubyがずっと遅かった。イライラしたけど、慣れて、今では楽しんでるよ。だけど、Makeの説明と使い方には問題があると思う！:-D 依存関係を使わないなら、何のためにあるの？ケース文でスクリプトを書いた方がマシだよ……真剣に言ってるわけじゃないけど、今の若者がMakeを理解できないのは、文化の悲しい反映だと思う……それと、私の庭から出て行ってくれ、いい？ :-)

└

ケースステートメントを使ったスクリプトを書いた方がいいかも… 最初はこれで始めて、シンプルなフラットMakefileに進化した。 基本的には同じだけど、Makeの方が標準的に感じるから（ここにMakefileがあるのに対して、ここにランダムなbashスクリプトがある）。

文法が人間に優しいだけでなく、PythonインタープリターがすべてのUnixディストリビューションにネイティブに統合されているからだ。これはかなり楽観的な評価だね。「import json」以上のことをしようとすると、仮想環境の深淵に引き込まれる可能性が高い。たとえば、Python 3.13.xで作成したものをUbuntu 22.04や24.04（LTS）/ Rocky 9で動かすと、いろいろな問題が出てくる。仮想環境やコンテナ（Dockerのような）/バージョン管理ツールがすぐに必須になるよ。

└

これはuvで解決されるよ。

└

“import json”は、バッテリーが含まれていない言語でライブラリを選んでインストールする必要があるようなことだし、標準ライブラリに含まれている多くのモジュールの一つに過ぎない。それは大規模なプロジェクトのための説得力のある基盤ではないけど、これまでに標準ライブラリだけで済んだ便利なプロダクションコードをたくさん出荷してきたから、デプロイやセキュリティパッチについて考える時間は全くなかった。あと、もう2000年代じゃないからね。アプリケーションのインストールを隔離するためにvenvを使うのは、もうそんなに難しくないし、長い間 decentなパッケージマネージャーもあったよ。

└

ちょっとバカげた理論なんだけど、docker/コンテナがこんなに早く普及したのは、ひどいPythonの依存関係地獄をうまく解決したからだと思ってる。 何かが悪いときは、豪華なchrootが動くものを出荷する唯一のエルゴノミックな方法になってる。 自分がPythonに触れたのは、2012年頃にサーバーにPythonで書かれたサービスをインストールしたとき。 依存関係地獄や、クソみたいなvenvコマンド、ウェブサーバーを動かすためにこんなに苦労するなんて、本当に大変だった。 それ以来、Pythonは10年以上も避けてた。 ほとんど見るたびに、興味がなくてその場を離れてた。 たまに使ったときは、またそのクソの山に戻って、なぜ普段避けてるのか思い出してた。 macOSのbrewの扱い方もすごくイライラする。 基本的なpip installコマンドを壊したり、ライブラリをコマンドとしてインストールするけど、他のPythonスクリプトで使えないようにするなんて、なんてクソな災害なんだ。 本当に何を話してるのか分からないけど、初心者としては、これが本当に愚かで混乱させられるから、もっと生産的で楽しい作業に移ってる。 「Pythonがちゃんとしたらまた考える」って心の中でメモしてる。 でも、uvは、少なくとも自分の初心者で皮肉な目には、ほとんどのクソを取り除いてくれた。 少なくとも表面的には、Pythonで始めた小さなおもちゃプロジェクトでは、ほとんどのひどいクソを取り除いてくれた。 uv init、uv add、uv run。 そして、ちゃんと動くんだ。

└

いつでも仮想環境を使うべきだよ。 一つのディレクトリだし、どうしてそれが深淵なの？ 今はpipが、パッケージをシステム全体にインストールしようとすると文句を言うよ。

Hacker Newsで議論の続きを見る