こんにちは、Pythonエンジニア育成推進協会 顧問理事の寺田です。私は試験の問題策定とコミュニティ連携を行う立場です。
2022年、2023年と続けて5月ごろにおすすめの開発環境についてお話してきました。
開発環境の構築に悩まれる方は多いようで、毎年、結構な人数の方が閲覧しているようです。
ということで、今年もPythonのおすすめ環境についてお話したいと思います。昨年公開した記事からのアップデートになります。昨年の内容が気になる方はそちらの記事を参照していただければと思います。
開発環境変遷、今年もあまりなし
まずは私自身の環境の変異です。少し変わったところはありますが、大きな変化はありません。
| 2017年時点 | 2022年 | 2023年 | 2024年 | |
| 1．実装 | CPython | CPython | CPython | CPython |
| 2．Pythonバージョン | 3.6 | 3.9 | 3.9か3.10 | 3.11か3.12 |
| 3．インストール方法 | 公式インストーラ | 公式インストーラ | 公式インストーラ | 公式インストーラ |
| 4．仮想環境 | venv | venv | venv | venv |
| 5．パッケージインストール | pip | pip | pip | pip or uv |
| 6．エディタ | PyCharm | VS Code | VS Code | VS Code |
■バージョンについて
- バージョンの選び方
Pythonは12カ月ごとにリリースされており、現在、Pythonの最新バージョンは昨年10月にリリースされた3.12です。リリースされてから半年が経っていますので、ほとんどの外部ライブラリも3.12に対応して安定しているものがほとんどです。
Pythonは基本的に下位互換が保たれている上、5年間のサポートがありますので、以前のバージョンであってもコードは基本的に動きます。最近のアップデートではタイプヒントやF-stringsなどが改善され、書き方がわかりやすくなったなどの機能面が向上していますが、メインとなるアップデートは内部の構造をスピードアップするようなもので、書いたコードが動かなくなるという事はほぼありません。
という背景から、私自身は、古いバージョンにこだわることも、あえて新しい方に行くこともなく、その時々でライブラリの対応状況などを含めて、3.11と、3.12を使い分けている感じです。
ちなみに、マイクロバージョン（例：3.12.1と3.12.0）を一つの環境に共存させることは、通常の方法ではできません。マイナーバージョン（例：3.11と3.12）なら共存可能です。
- Wheelの存在と利点
Pythonではpipコマンドを使ってパッケージのインストールをすることがほとんどだと思います。また、最近はインストールに必要なすべての必要な機能をパッケージ化されたWheel（拡張子.whl）というものがPyPIにアップされており、これを使用してインストールすることが増えています。whlはビルド済みのパッケージを配布するためのPythonの標準仕様です。
pandasやNumPyなどのページ内にあるファイルダウンロードページからダウンロードできます。パッケージビルダーによって作られたものになりますので、上がっていない環境ももちろんあります。そのため、ここにないバージョンを利用したい場合は、一から環境を作る必要があります。
例）pandas
引用）https://pypi.org/project/pandas/#files から一部分
アップされているファイル数は多いのですが、ファイルに書かれている名称でどの環境で使えるかが一目瞭然になっており、自分の環境に合ったWheelの有無を調べれば、ほとんどの場合は問題ない状態のものが手に入れられます。そう意識せずに使うことができると思います。
Wheelを使えば、適切にビルドされている状態になっているため、手間をかけずに環境を構築することができます。特にpandasやNumPyは本来、ソースコンパイルが必要ですが、環境ごとにビルドされたWheelがあれば、ソースコンパイルしてビルドする必要がなく、pipコマンドでとりに行くだけで済みますので、多大な恩恵を得られると思います。
なお、今後、予定されているPythonのバージョンアップでは、スピードアップなどを目的とした内部構造の改修が入ってきますので、アップされているWheelもビルドしなおさなければならないことも出てくる可能性があります。また、Wheelが提供されるタイミングは、Pythonの新しいバージョンが出てすぐとは限らず、その時によります。
■インストーラと仮想環境
- 引き続き、公式インストーラ
昨年に引き続き、PSF（Python Software Foundation）の公式インストーラを使用しています。
WindowsやmacOSであればインストーラを何度かクリックすれば完了しますし、Linuxの場合はソースコンパイルして公式のものを利用しています。
- 仮想環境とインストールは基本今まで通りも、パッケージ管理ツールuvを試用中
仮想環境は引き続き、venvを使用し、インストールにはpipコマンドを今でもメインで使用しています。が、最近、uvという新しいパッケージ管理ツールを使用し始めました。
こちらは、まず動きが高速で、venvとpipの機能を、uvというコマンドから使うことができます。新しいインストーラと考えていいと思いますが、サードパーティ製のもので公式ではありません。まだ開発が始まったばかりのもので、今後どのようになっていくかまだ分かりませんので、初めて学習される方にはお勧めしませんが、最近注目が集まっていることは確かです。
基本的に、私自身はあまり新しいパッケージ管理ツールに飛びつかない方なのですが、このuvに関しては、圧倒的に処理速度が速くなることもあって試用しています。
pipはバージョンが定期的に上がりますが、仮想環境を作るたびにpipのバージョンアップもしなければならないなど、慣れてくるとちょっとした手間になることがいくつかあります。標準のままではちょっと面倒なものや、速度に不満があるときには、uvが比較的同じようなコマンド体系で対応できることもあって利用しています。まだおすすめできるほど使い込んではいませんので、これから使い込んでみて考えようと思っていますので、1年後どうなるかはまだわかりません。
とりあえず、初心者の方はまず、サポートの手厚いvenvとpipでやり、不満が出てきたら別のものを検討してみましょう。
- Docker使用はその時々に
ところで、昨年の記事で、Dockerを利用することが増えていると書きました。確かに今でも使用していますが、Docker自体の面倒臭さはもちろんありますので、運用段階ならともかく、開発環境としてDocker使うという点については少々悩みどころに思い始めています。
Dockerに慣れているのであればそのままで構いませんし、Docker公式のPythonもありますので、そちらを使うでも問題ありません。また、エディタの項目で紹介するVS CodeとDev Containerの組み合わせでDocker技術を使う手段もありますが、そこまでしてDockerでなければならない理由はないため、最近は自身のパソコンで動かすことも増えています。
■エディタはVS Code
以前はPyCharmを使用していましたが、もう完全にVS Codeばかりになりました。もちろんPyCharmをも進化してはいますが、VS Codeは無料で使える上に、様々な拡張機能が充実しているため、やはりVS Codeを使うのがいいかなと考えています。
VS Codeは拡張機能にOpenAI社のChatGPTの技術をもとにしたコードアシスト機能であるGitHub Copilot拡張が使えます。もちろん、PyCharm側でもGitHub Copilotは使えますし、PyCharmを作っているジェットブレインズ社では、別のAIの仕組みも提供しています。
ただ、VS Codeは比較的使っている人が多く、さらにVS CodeでGitHub Copilotを使う人も多く、よくあるパターンだと思っています。
私はVS Codeを利用していますが、PyCharmも良いところはありますので、好みで使ってもらえればと思います。
ところで、コードアシストの仕組みは昨今ものすごい勢いで進化しており、1か月もあれば新しいものがどんどん出てくる時代です。
GitHub Copilotは有料のサービスなので、ライセンス上の問題などはありますので、全員がこれを使わなければならないという事はありません。が、PythonでもType Scriptでも、他の設定ファイルであっても、コードのアドバイスをしてくれる上に、同じような繰り返しの作業を行う場合にコードをパッとアシストしてくれます。
正直言えば、1回体験してしまえばもうやめられないぐらい作業効率が上がりますので、私自身は仕事でコードを書くときにはVS Code＋GitHub Copilotはもう当たり前のように使っています。
VS Codeを使わない場合は、GoogleのColaboratryや、JupyterLabを使った機械学習がよく使われていると思いますし、私ももちろん使います。ただ、実際には、JupyterLabが吐き出す.ipynbファイル（JupyterLabの内部でノートブックを扱うファイル形式）は、VS Codeからも読み書き、実行できます。
また、Google Colaboratryは共有する時や環境がない時にはもちろん便利ですが、やはり手元に環境があった方が圧倒的に良いと思っていますので、自分で環境作れる場合には作って、VS Codeを使っています。
そうした結果として、GitHub Copilotのコードサジェスチョンも.ipynbファイルに対しても使えるようになりますので、開発効率もUPしています。
- コードフォーマッターはBlack様からruffへの変更を検討中
ところでuvを作った会社は、実はその前にもうちょっと有名なライブラリを出しています。ruffと言うコードフォーマッターですが、このruffも最近使われることが増えています。
PythonにはPEP8というスペースの入れる箇所や、改行を入れる箇所などのルールがまとめられている標準コーディング規約があります。
コードフォーマッターは、その規約に合わせた修正をしてくれるもので、Flake8やautopep8など様々なツールが出ています。ここ最近の人気はBlackが定番でした。Blackはコードフォーマッターとして強制力が強く、自由度が低いものです。Blackだけだとチェックしきれない項目があり、Flake8と併用することが多いのですが、仕様がぶつかる部分があるため、一旦どちらかを無効化して使うことがあります。ただ、これだと再度有効化したときに衝突してしまうのに変わりはありませんでした。
このruffであれば、両方の機能を兼ね備えている上に高速なので、最近はこちらの方に切り替えようかと考え始めています。
コードは一度書けば終わりではなく、何度も見直して書き換えたり、レビューをしてもらったりしますので、統一的な書き方がされている方が非常に読みやすく、わかりやすくなります。
コーディング規約は人が守る形にするとどうしても曖昧性が残ります。コードフォーマッターが指示するものを正としてやっていく方が効率的ですし、同じフォーマットになりますのでおすすめです。
- コードアシスト機能と付き合う前に身に着けておきたいこと
AIによるコード生成は現状でもかなり上手く書いてくれているとは思いますが、今後、より進化していくはずです。適切に指示することができれば、適切な答えが返ってきますし、難しいアプリでも最適なコードが返ってきます。またテストコードを書かせるのにも向いています。
ただ、返されたコードを丸々信用してしまうと、変なコードだったことに後から気づき、ミスしてしまうこともありますので、コードが正しいものであるかどうかを人間が判断する必要があることは変わりないと思います。
適切に判断しながら、返ってきたコードが意図通りのものかどうかを判断しながら、コーディングしていくことを忘れないようにしましょう。
とはいえ、初学者の内はコードが正しいかはわからないと思いますので、正しいかどうか判断できないうちは、AIによるコードアシスタントは使わずに進めましょう。
初級から中級位に到達したところで、積極的にAIを使ってみて、正しいかどうかを判断する訓練をしていきましょう。
■さいごに
昨年から比べるとそう大きな変化はありませんが、AIや、新しいツールであるuvやraffなど、開発をしやすくする技術がどんどん登場しています。
環境なども含め、新しいものはこれからもどんどん増えていきますので、覚えなくてはならないことはたくさんありますが、Docker技術を使ったり、CI/CDを使ってみたり、いろいろなものを試しつつ、うまく1つずつ使いこなして、活用していっていただければと思います。