タグ

ブックマーク / methane.hatenablog.jp (17)

  • uvとRye - methaneのブログ

    先週にRuffを開発しているAstralがuvを発表しました。 astral.sh uvは現在のところはvenv, pip, pip-toolsの基的な機能を提供していますが、将来は"Cargo for Python"になることを目標にしています。 一見すると乱立しているPythonのパッケージ管理ツールにもう一つ加わったように見えますが、Ryeの開発者のArminとuvの開発チームは連携していて、同時に次のような発表をしています。 uv: Python packaging in Rust Rye Grows With UV | Armin Ronacher's Thoughts and Writings Ryeはもともとより良いパッケージツールがどうあるべきかの実証のために作られていて、中身は既存のツールのツギハギだった Ryeがpip-toolsやvirtualenvの代わりにuvを

    uvとRye - methaneのブログ
    sh19910711
    sh19910711 2024/05/03
    "uv: ”Cargo for Python”になることを目標 / 乱立しているPythonのパッケージ管理ツールにもう一つ加わったように見えますがRyeの開発者のArminとuvの開発チームは連携していて / uvがRyeの機能に追いつくまでRyeの開発は当面続く"
  • 判りやすいやり方が1つは必要だ -- その1つだけなら最高だね - methaneのブログ

    はじめてのにき(2016-03-10) を見て。 Python の Zen の一つ "There should be one - and preferably only one - obvious way to do it." はよく誤解される。 これはもちろん Perl の TMTOWTDI 「やり方は1つじゃない」に対するものなのだけど、反対の「やり方は1つが良い」という意味では決して無い。 現実的なプログラミング言語でそんなアホな目標を持ってはいない。訳すなら「判りやすいやり方が1つは必要だ -- その1つだけなら最高だね」で、 preferably~ の部分は補助的なものだ。 例えば conditional expresson x if cond else y は、普通の if/else 文と一時変数を使えば良いので、新しいやり方だ。でも、これがない時代は、一部のエキスパートが c

    判りやすいやり方が1つは必要だ -- その1つだけなら最高だね - methaneのブログ
    sh19910711
    sh19910711 2023/02/10
    2016 / "新しいやり方を追加するのは今までのやり方よりも明らかに読みやすく判りやすいなどのメリットがあるときで、ちょっとタイプ数を減らすとか好みの書き方だということではやり方を増やさないと"
  • len が関数になっている理由 - methaneのブログ

    http://d.hatena.ne.jp/pashango_p/20090702/1246550203 len()がリストのメソッドでないのも同じ理由です。 オブジェクト指向的に考えれば、リストのメソッドであるべきなのに、わざわざビルトイン関数にしたんです。 「オブジェクト指向的に考えれば、リストのメソッドであるべき」って感じで、オブジェクト信者はそれが正義みたいに考えちゃうんだろうね・・・ Pythonは合理主義。「オブジェクト指向的に○○」よりも、一貫した少なくて明確なルールを重視する。 len() が .length() メソッドだったらどうなるか。あるコンテナは .length() の代わりに、 .len() や .size() という名前を使ってしまうかもしれない。「サイズを取るメソッドは.length()」という 暗黙のルールができてしまい、そのルールが頭に入っていない人が一

    len が関数になっている理由 - methaneのブログ
    sh19910711
    sh19910711 2021/06/27
    "Pythonは、何かのルールに準拠するためのメソッドは「__???__」という形にする、という一般ルールをつくり、それを interface の代わりにした / __len__ に対するインタフェースは len() という組み込み関数"
  • CPython の GC チューニング - methaneのブログ

    ISUCON は Go で参戦しているんだけど、複数のチームが Python で予選通過したらしいので、応援のために Tips を公開していこうと思う。 目次 CPython の GC について 統計情報を出力する 第一世代GCの間隔を調整する Out of Band GC 循環参照を見つけて対処する CPython の GC について CPython のGCは参照カウント+循環参照コレクタだ。そして参照カウント方式は(幾つかの欠点はあるものの)Webアプリのボトルネックになったりはしにくい。 なのでGCチューニングの基は次のようになる。 循環参照を避ける 循環参照コレクタの呼び出しタイミングを制御する 循環参照コレクタは、生きているオブジェクトの数がある程度増えると第一世代が実行され、第一世代が一定回数実行されると第二世代が、第二世代が一定回数実行されると第三世代が実行される。 各世代

    CPython の GC チューニング - methaneのブログ
  • Unix Domain Socket において keep-alive が性能に与える影響 (Gazelle vs Meinheld) - methaneのブログ

    id:kazeburo さんが Gazelle という高速な Perl 用の Web アプリケーションサーバーを公開されました。 Gazelle - Plack Handler for performance freaks #yokohamapm from Masahiro Nagano Gazelle の特徴のうち幾つかは、 id:mopemope 作の Meinheld と同じです。 IO周りは全てCで書かれている accept4 や writev などの Linux 独自のシステムコールを利用している 一方で異なる点もあります。 Meinheld は HTTP/1.1 に対応していて、 keep-alive が利用できる。 Meinheld は greenlet というコルーチンを利用して、 long polling や SSE に対応している。 Meinheld が http-pa

    Unix Domain Socket において keep-alive が性能に与える影響 (Gazelle vs Meinheld) - methaneのブログ
  • CPython の Core Developer になりました - methaneのブログ

    Python 3.6 に取り込まれた dict の新実装などでコアコミッターに興味を持ってもらい、 Core Developer (要するにコミッター) に推薦しようか?という提案をもらいました。 最初はコミッターとか面倒そうだし、コミットメッセージとかNEWSエントリー(通常パッチをコミットするときにコミッターが書く)とかを英語で書くのも英語が得意な人がやったほうがいいだろうし、とりあえず github に移行するまでは様子見しておこうと思ってたのですが、 dict 関係のパッチがいくつもレビュー待ちでなかなかコミットされないのを見て「やっぱりアクティブなコミッターが全然足りてない」と考え直し、志願することに。 で、先月末にコミット権をもらった(というか push できる権限を持った hg アカウントに ssh 鍵を登録してもらった)のですが、新米コミッターは簡単なパッチでも他のコアコミ

    CPython の Core Developer になりました - methaneのブログ
  • Python の新しいプロファイラ vmprof が面白い - methaneのブログ

    PyPy 2.6 と同時に、 vmprof という CPython/PyPy 用のプロファイラが登場しました。 私はまだ PyPy では使っていませんが、CPythonプロジェクトをこれでプロファイル取ってみたらなかなか面白かったので紹介します。 概要 Python にはもともと標準ライブラリとしてプロファイラ (cProfile) が付いてきていますが、これは関数の呼び出しと戻りでコールバック関数を呼び出しつつ実行時間を計測するタイプのプロファイラで、短時間でも正確なプロファイルが取れる反面、オーバーヘッドが大きく、小さい関数をたくさん呼び出す部分がオーバーヘッドでより大きく見えてしまうなどの問題がありました。 これと別の種類のプロファイラとして、定期的にサンプリングして、サンプルが多いところが実行時間も多いハズ、というプロファイラもあります。こちらはある程度の量のサンプルを集めないと

    Python の新しいプロファイラ vmprof が面白い - methaneのブログ
  • 依存するパッケージは厳選しよう - methaneのブログ

    japan.zdnet.com JS界隈が大騒ぎになった事件だけど、こういった事件自体は完全に防ぐことは不可能だと思う。 今回は依存ライブラリが削除されるだけで済んだけど、 npm install するだけで ~/.ssh ディレクトリを zip にしてどこかに送信するような悪質な攻撃であれば、単にCIが止まるどころでなく、世界中のエンジニアの秘密鍵がばらまかれてあちこちのサーバーにssh可能な事態になったわけで、そんな悪質な攻撃を bugfix なマイクロバージョンアップとして公開される事もありえたわけだ。 第三者のパッケージに依存するということは、それだけのリスクを背負い込むということだ。だが、逆に外部のライブラリに依存しないようにすると、生産性が落ちてしまう。 なので、コードを読む、信頼できるメンテナの公開しているパッケージを選ぶなどといった方法で、リスクとメリットのバランスを取って

    依存するパッケージは厳選しよう - methaneのブログ
  • Go で書いたサーバーを管理するには circus が便利 - methaneのブログ

    Go を使うとサーバーとアプリケーションの境界が無くなり、アプリケーションサーバーを書けるようになります。 それは良いことなのですが、アプリケーションを書く人が、従来サーバーを書く人が設計していた機能を理解して実現できないと、運用できないサーバーができあがる結果になってしまいます。 例えば Apache は、 master, worker プロセスが分離していて、設定変更を反映させるときなどは新しい worker を作ってから古い worker を殺すことで、サービスを一瞬も止めずに worker を再起動していました。これを graceful restart と呼びます。 Go で 1024 以下のポートを Listen するアプリを作る で触れたとおり、 Go はプロセス管理システムを作るのには少し向いていない面がありますし、せっかくアプリケーションプログラマーが簡単にサーバーを書ける

    Go で書いたサーバーを管理するには circus が便利 - methaneのブログ
  • BitBucketのいいところ - methaneのブログ

    KLab では、プロジェクト開発中に作った便利ツールなどを皆が気軽に社内で公開できる場としてBitBucketの無制限プラン($200/month)を契約しています。 今日は Github に比べていいなと思う点を紹介していきます。 1. アクセスコントロール Githubだと、書き込み権とadmin権が一緒になってしまっていましたが、BitBucketではadmin権とwrite権が分かれていたり、Team(GithubでいうOrganization)の Owner グループでなくてもリポジトリを作ることができます。 特にadmin権がなくてもリポジトリが作れるので、「皆に気軽にリポジトリを作って欲しい」を実現するために皆に Team の admin権を渡さなくていいのが利点です。 deploy key についても、同じ公開鍵を複数のリポジトリに登録できるのと、pushが禁止されているの

    BitBucketのいいところ - methaneのブログ
  • 次世代標準非同期I/Oフレームワーク asyncio (Tulip) - methaneのブログ

    Python Advent Calendar 2013 の4日目です。 Python 3.4 で標準ライブラリに追加される asyncio を触ってみます。 なお、 Tulip とは asyncio のリファレンス実装のプロジェクト名です。 背景 Python はよく非同期 I/O プログラミングに使われます。 Twisted, Tornado, gevent, eventlet, pyuv などのフレームワークがあります。 これらのフレームワークの問題点として、ライブラリの再利用性の低さが挙げられます。 たとえば Twisted 用に書かれた XMPP ライブラリは、そのままでは Tornado で 利用することができません。 この問題の解決策として、良くイベントループの乗り入れが行われます。 GUIアプリケーションに組み込む場合などを考えて、多くのフレームワークが最初から イベントルー

    次世代標準非同期I/Oフレームワーク asyncio (Tulip) - methaneのブログ
  • 言語とリーダビリティ - methaneのブログ

    この記事は 勝手に添削: PHP初心者向けのコード最適化 の続編です。リーダビリティの定義は前と同じく、「そのコードが何をしたいかを把握する時間+そのコードをレビューして正しいと自信を持てるまでの時間」の短さです。 よく「php よりも Python の方がリーダビリティが高い」という主張に対して、「Pythonでも糞コードはかける」「言語よりも人の問題だ」といった反論をする人がいます。 この反論をする人は「同じ程度のスキルの人が同じ程度の丁寧さでコードを書く」という暗黙の前提が伝わっていなくて、「リーダビリティは言語に依存して人には依存しない(あるいは人よりも言語に強く依存する)」という主張だと誤解しています。(この主張にかぎらず、大抵「◯◯でも悪い△△は存在する」という類の反論は、暗黙の前提を理解していないか、あるいはわざと無視しているケースが多いです) 言語設計が(書き手のスキルほど

    言語とリーダビリティ - methaneのブログ
    sh19910711
    sh19910711 2014/08/14
    "リーダビリティの単位は「時間」なので、学習コストと天秤にかけることができます"
  • Python 2/3 両対応のために `unicode_literals` を使うべきか - methaneのブログ

    背景 Python 2 用のコードを書くときは、 Python 3 対応を見越して # -*- coding: utf-8 -*- from __future__ import division, print_function, absolute_import をテンプレとして書いています。 __future__ はファイルごとにバラバラだと混乱を招くので、今関わってるプロジェクトでもこれを新規ファイルのテンプレとして登録してもらってます。 Python 3 の構文、リテラルを有効にする __future__ のうち、 unicode_literals だけは今まで使っていなかったのですが、ふと「あ、やっぱり使うべきだな」と思いついたので、そのへんをまとめます。 第三の文字列型 native string Python 2 には2つの文字列型 str (bytes) と unicode が

    Python 2/3 両対応のために `unicode_literals` を使うべきか - methaneのブログ
  • Python 3 の MySQL ドライバ事情 - methaneのブログ

    Python 3.3 の現状の MySQL 事情ってだいぶ解りにくいので、 MySQL-python と PyMySQL についてまとめておきます。 MySQL Connector/Python とかも Python 3 対応しているはずですが使ってないので知りません。 MySQL-python 多分デファクトスタンダードな MySQLドライバなのですが、現状リリースされている 1.2.4 では Python 3 対応ができていません。 Fork の MySQL-for-Python3 が推奨されます。 PyMySQL 一応、この前リリースした PyMySQL 0.6 で動くはずです。 速度的には CPython で使う文には MySQL-python の方が速いはずなので、そっちを使ったほうがいいです。 また、 PyMySQL 0.6 はプロトコル仕様みながら結構書き換えたので人柱要素も

    Python 3 の MySQL ドライバ事情 - methaneのブログ
  • iterable と iterator - methaneのブログ

    イテレータを介して見るPHPクラスの内部構造 を読んだのですが、 最近の php はちゃんと Python などの言語を参考にしてるなーと思うことが多かったのにこの仕様は残念です。 Python など多くの言語では、イテレータの取得とイテレータの使用を明確に区別しています。 Python ではイテレータを取得できるオブジェクトを iterable と呼び、イテレータを iterator と呼びます。 iterable は __iter__ メソッドを実装し、 iterator は __next__ メソッド (Python 2 では next)を実装します。 また、 iterator は同時に iterable も実装し、自分自身を返すようにします。 これにより、 for 文などは「イテレータを取得しそれをイテレートする」というシンプルな動作ができます。 iterable と iterat

    iterable と iterator - methaneのブログ
  • Python の WebSocket ライブラリ - methaneのブログ

    ちょっと調べてみたら、想像してたよりもライブラリが充実していたので、各ライブラリの特徴をまとめておきます。 AutobahnPython Autobahn が Python 用にサーバー、クライアント用のライブラリを提供しています。 AutoBahn Python は Pure PythonTwisted に依存しています。 Twisted を使うなら Autobahn でいいのですが、そうでない場合は別のものを使う必要があります。 Autobahn は Python 用以外に JavaScriptJava(Android) 用にもライブラリを提供していて、また他の多くのプロジェクトでも利用されている WebSocket 用のテストスイートも提供しています。高品質な WebSocket ライブラリがいっぱい揃っているのは多分このテストスイートのおかげでしょう。 Tornado

    Python の WebSocket ライブラリ - methaneのブログ
  • Python で TDD してみる - methaneのブログ

    RSpec の入門とその一歩先へ がとてもよい記事だったので、 Python で写経させてもらいました。 https://github.com/methane/pytest-tut Ruby コミュニティと Python コミュニティの考え方の違いも見えて面白いと思います。 環境は Python 3.3 で、実行には py.test コマンドを使いましたが、 py.test の機能は特に使っていないので nose でもなんでも大丈夫です。 ファイルの作成 まずは空の実装とテストを作ります。 message_filter.py class MessageFilter: pass message_filter_test.py 最初のテストを書く py.test は .should といったメソッドを勝手に生やしたりはしません。普通に assert 文を書きましょう。 --- a/messege

    Python で TDD してみる - methaneのブログ
  • 1