はじめに Pythonの開発環境をどう構築するかというのは皆さん悩んでいるのではないかと思います。 私もずっと悩んでいました。悩んでいたというより毎回試行錯誤しながら、それぞれのツールを試していました。 本当に多くの選択肢があり、どれを選べば良いのか難しい状態になっていると感じています。 私が使用してきた範囲だけでも下記のような選択肢がありました。 Pythonのバージョン管理: pyenv、asdf、mise パッケージ管理: pyenv、poetry、rye、uv フォーマッター: black + isort、Ruff 型チェック: 使わない、mypy リンター: pylint、flake8、Ruff タスクランナー: Makefile, taskipy、poethepoet、Task そんな中で、個人的にようやくこれだ！と思える組み合わせにたどり着くことができました。 この記事では、
なお、testcontainers-mysqlはすでにメンテナンスされていないため、使わないでください。 対象コード MySQLに接続し、値を読み書きするだけの簡単なコードです。 testcontainersのドキュメントではSQLAlchemyを使用する方法を紹介しているので、O/Rマッパーは使用せず、PyMySQLでべた書きしてみました。 import pymysql import pymysql.cursors import typing def connect_db(host:str, user:str, password:str, database:str, port=3306): connection = pymysql.connect(host=host,user=user,password=password, database=database,port=port) ret
PyTorch v1.12 以降では、macOS において Apple Silicon あるいは AMD の GPU を使ったアクセラレーションが可能になっているらしい。 バックエンドの名称は Metal Performance Shaders (MPS) という。 意外と簡単に使えるようなので、今回は手元の Mac で試してみた。 使った環境は次のとおり。 GPU が 19 コアの Apple M2 Pro を積んだ Mac mini を使用している。 $ sw_vers ProductName: macOS ProductVersion: 14.4.1 BuildVersion: 23E224 $ sysctl machdep.cpu.brand_string machdep.cpu.brand_string: Apple M2 Pro $ pip list | grep -i tor
みなさん、こんにちは！私は株式会社ulusageで技術ブログを担当しているエンジニアです。最新の情報や、日々の開発で役立つTipsを皆さんと共有していきたいと思います。どうぞよろしくお願いします。（もしこのブログの仕組みやシステムフローに興味があれば、ぜひお知らせください。皆さんのご要望に応じて、詳細な記事を作成します！） Pythonでのデバッグ：print()からic()へ、革新の手法 はじめに Pythonで開発を進める中で、皆さんも一度は「なぜこのコードは期待通りに動かないのだろう？」と頭を抱えたことがあるのではないでしょうか。そのようなとき、print()関数を使って変数の値を出力し、デバッグを行うのは一般的な手法です。しかし、複雑なコードや大規模なプロジェクトでは、print()だけでは限界があります。今回は、そのデバッグ手法を一歩進めるためのライブラリ「IceCream」とそ
はじめに ニュージェネレーションズ！ nikkieです。 Python使いのみなさん、ジェネレータ使ってますか？ 私は多用しています、もう手放せません！ そんなジェネレータ（を返す関数）の型ヒントについてアウトプットします。 目次 はじめに 目次 ジェネレータ関数って、何よ？ 現時点の私の結論 動作環境 typing.Generator collections.abc.Generator 別のやり方：IteratorやIterable なぜ3通りも書ける？ 継承関係をもとに考える 終わりに P.S. その1 どうしてtypingの各種クラスが非推奨なんですか！ P.S. その2 types.GeneratorType ジェネレータ関数って、何よ？ 端的に言えば、yieldを持った関数です。 def generator_function(): yield "👩<200d>🎨" yield
本文中コード github.com flat layoutとsrc layoutについて Pythonプロジェクトのディレクトリ構成について調べてたところ、flat layoutとsrc layoutという2種類のディレクトリ構成が存在することを知りました。 src レイアウト対フラットレイアウト - Python Packaging User Guide flat layout flat layoutはパッケージフォルダをプロジェクトのルート直下に配置するスタイルです。 flat layoutの有名なpythonプロジェクトだと、 pytorch, django, tensorflow があります。 . ├── README.md ├── pyproject.toml └── my_package/ ├── __init__.py └── module.py src layout 一方、
PyCon JP 2024 ※ 資料中で絵文字を使用したら SpeakerDeck アップロード時になんか変なことになってしまいましたが気にしないでください
はじめに 美咲ちゃのおてて、ふわっふわ...😇 nikkieです。 先日 uv 0.3.0 を紹介しましたが、そのすぐ後に 0.4.0 が登場！ 0.4.0のリリースノートより、興味を持った点を調べました。 目次 はじめに 目次 uv 0.4.0 リリースノート 百聞は一見に如かず 「Creating projects」（Projectsのドキュメントより） アプリケーション（--app） ライブラリ（--lib） --app --package 「Build systems」も確認 uv init のドキュメント 終わりに uv 0.4.0 リリースノート This release adds first-class support for Python projects that are not designed as Python packages (e.g., web applic
なお、distrolessのイメージは2種類（3通りの名前）がありますが、Python 3.5はバグ修正はせず、セキュリティ修正のみでサポート期限が2020/9/13というステータスなので、本エントリーでは3.7の方のみを扱います。 gcr.io/distroless/python3: Python 3.5.3 gcr.io/distroless/python3-debian9: Python 3.5.3(上のイメージと同一) gcr.io/distroless/python3-debian10: Python 3.7.3 一応サンプル等もありますが、どれも1ファイルで構成されたサンプルスクリプトばかりです。前回のsite-packagesにコピーする方法を軽く試したところうまく動かず、シェルもpipもensurepipもないため、ビルドイメージにすることもできません。いろいろ調べた結果、
BusterとかStretchという名前が見慣れない方もいるかもしれませんが、これはLinuxディストリビューションとしてシェアの大きなDebianのコードネームです。 Debianバージョンが少し古いStretchの方がちょびっとサイズが小さかったりはしますが、まあ実用的にはサポートが長い方がいいですよね。slimを使ってGCCとかのコンパイラを自前でダウンロードしている記事とかもたまに見かける気がしますが、マルチステージビルドであれば、そんなにケチケチしなくていいのと、パッケージダウンロードは逐次処理なので遅く、処理系が入ったイメージのダウンロードの方が高速です。並列で処理されるし、一度イメージをダウンロードしてしまえば、なんどもビルドして試すときに効率が良いです。また、多くのケースでネイティブのライブラリも最初から入っており、ビルドでトラブルに遭遇することはかなり減るでしょう。 Py
pyenv + venvでPython3環境を構築する - $shibayu36->blog;の記事で、Python3でvenvを使った環境を構築することができた。しかしvenvでsource bin/activateすると、自分の設定したプロンプトの左側に(venvの環境名)という文字列が勝手に挟み込まれてしまって、あまり好みではなかった。 それを以下のように、venv環境の中にいたらpy:(pythonのversion):(venvの環境名)という表示にしたかった。 のでやってみた。 プロンプトの左側の環境名表示を消す まずプロンプトの左側の(venvの環境名)を消す。こちら を参考にして、VIRTUAL_ENV_DISABLE_PROMPTという環境変数を設定しておけば良いらしい。 # virtualenvでpromptを変更しない export VIRTUAL_ENV_DISABL
はじめに こんにちは！NFLabs. 研究開発部の林です。普段はセキュリティ教育プラットフォームの開発をしています。 今回はセキュアコーディングの重要な要素である「バリデーション(入力検証)」に関連して、PythonのPydanticライブラリにフォーカスしてお話します。 Python界隈では、昨今、型ヒントやFastAPIの普及に伴い、型の重要性や有用性が徐々に認識されつつあるかと思います。 それに伴い、バリデーションライブラリのデファクトスタンダードの一つであるPydanticの注目度も上がってきたと感じています。 Pydanticは実行速度の速さを特長として挙げていますが、Pydanticがもたらす安全性・Immutable(不変)性は、開発速度向上にも一役買っています。 本稿ではPydanticがいかに開発速度・開発体験に寄与するか考察します。 ちなみに、タイトルの「イミュータブル
今回は関数型プログラミングの中で頻繁に登場するカリー化というテクニックを紹介します。 カリー化はpartial関数のシンタックスシュガーであるためpartial関数について知っていれば難しくはありません。partialの復習も兼ねてカリー化と比較しながら紹介します。 partial関数のおさらい partial関数は関数に部分適用できる機能を持っています。 例えば、引数を２つ受け取りその積を返す関数mul(a, b)があります。どんな数値も2倍にする関数doubled(b)が欲しい場合は、partial関数を使って以下のように作成できます。
私が普段使っているPythonの開発環境の構築について説明します。DockerとPoetryを利用して構築し、1人または少人数で利用することを想定した開発環境です。 本稿では、はじめに最低限の構成でJupyterLabを起動する方法までを説明します。後にオプションとしてVS CodeやGitHub Codespacesの各種設定やフォーマッター、テスト、API構築などのトピックを扱います。使っているエディタなどに合わせて、必要なところだけ参考にしてください。 なぜDocker+Poetryという構成が良いのか、他の選択肢にはどういった物があるのかという点については、Pythonの開発環境の3つの観点をおさえようという記事に詳しく説明されています。 実行環境 Debian 11.7 Docker version 24.0.6 Docker Compose version v2.21.0 Li
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く