Docker のマルチステージビルドで自前でビルドした Wheel を含むイメージを作る - CUBE SUGAR CONTAINER
今回は Docker のマルチステージビルドを使って Wheel が提供されていない Python パッケージを含む Docker イメージを作ってみる。 これだけだと、なんのこっちゃという感じなので、以下で前提から説明しておく。 まず、今の Python のパッケージングにはソースコード配布物 (sdist) と Wheel という二つのフォーマットが主に使われている。 ソースコード配布物は、文字通りソースコードをそのままパッケージングしたもの。 ソースコード配布物では、パッケージの中に Python/C API などで書かれた拡張モジュールがあっても、ソースコードの状態で含まれる。 それに対して Wheel は、拡張モジュールが含まれる場合にはビルドされたバイナリの状態で提供される。 そして、現行の pip はソースコード配布物をインストールするとき、一旦 Wheel にビルドした上で
Python: Twine を使って PyPI にパッケージをアップロードする - CUBE SUGAR CONTAINER
Python のサードパーティ製パッケージは、一般に PyPI (Python Package Index) というリポジトリに登録されている。 このリポジトリはユーザ登録さえすれば誰でも自分で作ったパッケージをアップロードできる。 今回は Twine というツールを使って PyPI にパッケージをアップロードしてみる。 PyPI - the Python Package Index : Python Package Index 使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.12.6 BuildVersion: 16G1114 $ python --version Python 3.6.3 $ twine --version twine version 1.9.1 (pkginfo: 1.4.1, reques
Python: SQLAlchemy で悲観的・楽観的排他制御を試す - CUBE SUGAR CONTAINER
以前、MySQL を使ってリレーショナルデータベースの悲観的・楽観的排他制御を試してみた。 今回は、その悲観的・楽観的排他制御を Python の O/R マッパーの SQLAlchemy で実際に使ってみることにする。 blog.amedama.jp 使用する MySQL のバージョンは次の通り。 $ mysql -u root -e "show variables like 'version'" +---------------+--------+ | Variable_name | Value | +---------------+--------+ | version | 5.6.26 | +---------------+--------+ トランザクション分離レベルはデフォルトの REPEATABLE READ を使う。 $ mysql -u root -e "select @
Python: pandas の永続化フォーマットについて調べた - CUBE SUGAR CONTAINER
以前、このブログでは pandas の DataFrame を Pickle として保存することで読み込み速度を上げる、というテクニックを紹介した。 blog.amedama.jp 実は pandas がサポートしている永続化方式は Pickle 以外にもある。 今回は、その中でも代表的な以下の永続化フォーマットについて特性を調べると共に簡単なベンチマークを取ってみることにした。 Pickle Feather Parquet 使った環境とパッケージのバージョンは次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.13.5 BuildVersion: 17F77 $ python -V Python 3.6.5 $ pip list --format=columns | egrep "(pandas|feather-format|
Python: pep8 は pycodestyle になったし pep257 は pydocstyle になった - CUBE SUGAR CONTAINER
意外とまだあんまり知られていないような気がしたので、このブログにも書いておく。 PEP8 と pep8 と pycodestyle Python には PEP8 という有名なコーディングスタイルガイドラインがある。 www.python.org そして、そのコーディングスタイルに沿ったコードになっているのかをチェックするツールとして pep8 というパッケージがあった。 pypi.python.org 過去形にするのは半分正しくなくて、上記のように今もある。 ただ、これは後方互換のために残されているだけで、もうバージョンアップはされないだろう。 今後は代わりに pycodestyle というパッケージを使うことになる。 pypi.python.org これは単にパッケージとコマンドの名前が変わっただけ。 とはいえ、こちらはバージョンアップが続くので最新の PEP8 に追従していくしチェック
Python: tox を使って複数のバージョンでテストを実行する - CUBE SUGAR CONTAINER
先日の記事で Python 2.x/3.x の互換性に関するツールをいくつか紹介したけど、詳しい使い方までは書くことができなかった。 今回は、その中のひとつ tox の使い方について紹介してみる。 なんで tox が必要なのか プロジェクトを複数のバージョンの Python に対応させるには自動化されたテストが必要になる。 本当にそのバージョンでソースコードが動作するかは、実際に動かしてみないと分からないため。 ただ、テストがあったとしても複数のバージョンでそれを実行するのを手動でやっていては手間もかかるしミスも出る。 tox は複数のバージョンで一度にテストを実行してくれるため、その手間とミスを大幅に減らすことができる。 記事の全体の流れ 今回は tox を実際にサンプルのプロジェクトを用意して使ってみることにする。 流れは次の通り。 pyenv で複数のバージョンの Python をイ
Python: データパイプライン構築用フレームワーク Luigi を使ってみる - CUBE SUGAR CONTAINER
最近になって、バッチ処理においてデータパイプラインを組むためのフレームワークとして Luigi というものがあることを知った。 これは、Spotify という音楽のストリーミングサービスを提供する会社が作ったものらしい。 似たような OSS としては他にも Apache Airflow がある。 こちらは民宿サービスを提供する Airbnb が作ったものだけど、最近 Apache に寄贈されてインキュベータープロジェクトとなった。 Luigi の特徴としては、バッチ処理に特化している点が挙げられる。 ただし、定期的にバッチ処理を実行するような機能はない。 そこは、代わりに cron や systemd timer を使ってやる必要がある。 また、本体もそうだけどデータパイプラインについても Python を使って書く必要がある。 今回は、そんな Luigi を一通り触ってみることにする。
統計: ピアソンのカイ二乗検定で標本が理論分布と適合しているか調べる - CUBE SUGAR CONTAINER
例えば、ある六面ダイス (サイコロ) に歪みがないことを調べたいとする。 もしサイコロに歪みが無いなら、出る目の理論的な度数分布はどれも となるはず。 しかし、サイコロの出る目は無限母集団なので、実際にすべてのパターンを試して確認することができない。 つまり、全数調査は不可能ということ。 そのため、歪みがあるか否かは実際に何度かそのサイコロを振った有限な結果から推測する必要がある。 これはつまり、標本から母集団の分布を調べる推測統計になる。 上記のようなシチュエーションでは、今回紹介するピアソンのカイ二乗検定という方法が使える。 ピアソンのカイ二乗検定で適合度を調べると、実際に振ってみた結果から母集団が理論分布となっているか否かが判断できる。 この検定はノンパラメトリックなので、特定の分布の仕方には依存しないところが便利に使える。 ピアソンのカイ二乗検定の公式 (適合度) まず、ピアソンの
Python: ソケットプログラミングのアーキテクチャパターン - CUBE SUGAR CONTAINER
今回はソケットプログラミングについて。 ソケットというのは Unix 系のシステムでネットワークを扱うとしたら、ほぼ必ずといっていいほど使われているもの。 ホスト間の通信やホスト内での IPC など、ネットワークを抽象化したインターフェースになっている。 そんな幅広く使われているソケットだけど、取り扱うときには色々なアーキテクチャパターンが考えられる。 また、比較的低レイヤーな部分なので、効率的に扱うためにはシステムコールなどの、割りと OS レベルに近い知識も必要になってくる。 ここらへんの話は、体系的に語られているドキュメントが少ないし、あっても鈍器のような本だったりする。 そこで、今回はそれらについてざっくりと見ていくことにした。 尚、今回はプログラミング言語として Python を使うけど、何もこれは特定の言語に限った話ではない。 どんな言語を使うにしても、あるいは表面上は抽象化さ
Python: Pykka でアクターモデルについて学ぶ - CUBE SUGAR CONTAINER
アクターモデルというのは、並行処理のプログラミングモデルの一つだ。 並行処理という言葉からは、まずマルチスレッドとかをイメージすると思うけど、それよりも抽象度の高い概念となっている。 つまり、アクターモデルというのはマルチスレッドなどを用いて構築することになる。 どちらかといえばプロセス間通信 (IPC) の技法であって、共有メモリやロック、RPC と比較するものかもしれない。 そんなアクターモデルは、概念とか使ったときの嬉しさを理解・実感するのがなかなか難しいモデルだとも思う。 理由としては、使い始めるまでに必要なコード量が多かったり、それなりの規模のアプリケーションで使わないとメリットが分かりづらい点が挙げられる。 ただ、これはあくまで主観的なものだけど、アクターモデルをベースに組まれたアプリケーションは規模が大きくなっても並行処理をしているコードが読みやすい。 共有メモリやロックを使
Python: uptime でシステムの連続稼働時間を得る - CUBE SUGAR CONTAINER
システムの uptime (連続稼働時間) に関する情報はプラットフォームごとに取得する方法が異なっている。 今回紹介する Python の uptime パッケージは、それらの差異を吸収して共通の API で連続稼働時間を知ることができる。 今回使った環境は次の通り。 $ sw_vers ProductName: Mac OS X ProductVersion: 10.11.4 BuildVersion: 15E65 $ python --version Python 3.5.1 インストール uptime を pip コマンドでインストールする。 $ pip install uptime 使ってみる 使い方はシンプルこの上ないので REPL を使って示す。 python コマンドで起動しよう。 $ python 連続稼働時間は uptime モジュールの uptime() 関数で得られ
Python: Janome で手軽に形態素解析する - CUBE SUGAR CONTAINER
Janome は Pure Python で実装された日本語の形態素解析ライブラリ。 形態素解析というのは文章から意味をもった最小の構成単位となる形態素を取り出すことをいう。 他の日本語の形態素解析ライブラリは Python から使えてもバインディングが提供されているだけでドキュメントがイマイチだったり、あるいはインストールが大変だったりということも多々あるんだけど Janome はそんなことがない。 インストール インストールは実に簡単。 pip を使ってさっくりできる。 $ pip install janome 使ってみる 使い方も至ってシンプルで janome.tokenizer.Tokenizer さえ知っていればいい。 Tokenizer#tokenize() メソッドに日本語のユニコード文字列を渡すだけで解析ができる。 解析結果はリストで返ってくる。 >>> from jano
Python: コマンドラインパーサの Click が便利すぎた - CUBE SUGAR CONTAINER
Python のコマンドラインパーサといえば、標準ライブラリに組み込まれている argparse が基本。 蛇足になるけど、バージョン 2.7 以前で使われていた optparse は将来的に廃止予定なので新たに使うことは避けた方が良い。 そして、今回紹介する Python のサードパーティ製コマンドラインパーサ Click は、既存のパッケージと比較すると最小限のコードで美しくコマンドラインインターフェースを実装できるように作られている。 どれくらい楽になるかといえば、もう argparse を使っている場合じゃないな、と思えるレベル。 Welcome to Click — Click Documentation (8.0.x) もくじ もくじ Click をインストールする 基本的な使い方 コマンドを定義する オプションを追加する 引数を追加する サブコマンドを作る オプションについて
Python のバージョン毎の違いとその吸収方法について - CUBE SUGAR CONTAINER
この記事の目指すところ 現在 Python はバージョン 2.x 系と 3.x 系という、一部に互換性のないふたつのメジャーバージョンが併用されている。 その上で、この記事にはふたつの目的がある。 ひとつ目は、2.x 系と 3.x 系の違いについてまとめること。 現状、それぞれのバージョン毎の違いはまとまっているところが少ない。 自分用に、このページだけ見ればひと通り分かる！っていうものがほしかった。 ふたつ目は、2.x 系と 3.x 系の違いを吸収するソースコードの書き方についてまとめること。 こちらも Web 上にナレッジがあまりまとまっていない。 これについては今 python-future というパッケージがアツい。 尚、サポートするバージョンは以下の通り。 2.x 系: 2.6 と 2.7 3.x 系: 3.3 と 3.4 本題に入る前に、最近の Python 事情についてまとめ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
