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 が
pip install や easy_install を速くするための pypi の設定変更 - methaneのブログ
pip や easy_install が突然速くなるかもしれない で紹介した pypi からのインストール高速化の第一弾が始まりました。 といっても、いきなり勝手に pypi 側でスクレイピングするURLを変更するのではなくて、パッケージ管理者が明示的に指定する方法になります。 pypi にパッケージをアップロードしている人は設定変更しましょう。 パッケージの管理画面のうち url の画面を開くと、この画像のようなページが表示されます。 まず、 Hosting Mode のところで、 "As above but also..." になっているのを "Do not extract..." に変えます。これで、アップロードしたファイル以外を探しに行くことがなくなります。 (pypi にパッケージをアップロードしていない人は、 download_url を指定して "Present URLs..
Python でファイルを直接イテレータとして使うのが適切でない場合 - methaneのブログ
Pythonでサブプロセスと対話する - 西尾泰和のはてなダイアリー Python のファイルは、通常のファイルの読み込みの効率を考えて大きめ(8192バイト)のバッファリングを行っているので、ソケット通信やパイプで問題になるケースがある。 問題になるケースの一つがファイルオブジェクトをイテレータとして使って行単位の処理をする場合で、 for line in fileobj: do_something(line) のようなコードを書くと、実際には fileobj の中にあるCのFILEから一気に読み込み、その中から改行文字を探して切り出していくので、8192バイト読み出せるかファイルの終端に到達するまでブロックしてしまう。 一方、 file.readline() は、改行を見つけるまで getc() を繰り返すか、(UnixでUniversal Newlineを使わない場合は)fgets
PythonでGmailにIMAP経由でアップロードしてやんよ - methaneのブログ
経緯 いまさらだが、ローカルにためてたメールをGmailにアップロードしてみた。最初はThunderbirdでIMAP4の設定をして、Thunderbirdで選択＋移動でアップロードしていたのだが、(1)ときどきConnectionが切れる、(2)時々Gmailがエラーを返す、ために移動が止まってしまう。しかも、複数選択した状態で移動に失敗すると、アップロードに成功したメールも移動元に残ってしまい、どのメールをアップロードしたのかわからなくなってしまう。 なので、一回あたり数十通だけを選択してチマチマアップロードしていたのだが、一つ目のディレクトリをアップロードした時点残りのメールの量に絶望した。 下調べ とりあえず、imapとmboxを扱うライブラリが無いかとcheese shopを物色してみるも、殆ど無い。そういえば標準ライブラリにあった気がすると思い出して、標準ライブラリの法を調べて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
