2011年7月12日火曜日

Windows 向け Python ランチャー

原文はこちら: A Python Launcher For Windows

Mark Hammond (pywin32 の作者であり、長い間 Windows 環境の Python サポーター) は、 PEP 397 を提案しました。その PEP は Windows 環境の新たな Python ランチャーについて記述したものです。Vinay Sanjip (標準ライブラリ logging モジュールの作者) は、つい先日そのランチャーを実装して、いま https://bitbucket.org/vinay.sajip/pylauncher/downloads からダウンロードできます。

このランチャーは、Python 2 と 3 が同時に利用可能であり、Windows 環境の Python スクリプト (.py.pyw ファイル) に対して、実行する Python のバージョンを指定します。

Windows ユーザーは、残っている問題を解決する Python 開発者を支援するために、このランチャーをダウンロードしてテストすることを検討してください。このランチャーは、独立したアプリケーションとしてパッケージングされていて、現在、利用できる Python のバージョンをサポートします。目的としては、ランチャーが完成したら、Python 3.3 の一部として提供する予定です。(依然として、以前のバージョンのユーザー向けに独立したアプリケーションとして利用できるようにする予定ではあります)

このランチャーは2つのバージョンが利用できます。 Program Files ディレクトリにインストールする launcher.msi と、Windows の System32 ディレクトリにインストールする launchsys.msi です (64 ビット Windows 向けの 64 ビットバージョンも用意されています) 。

ランチャーについての詳細


ランチャーの動作についての完全な仕様は PEP 397 に記述されています。次に基本的な原則をまとめます。

  • ランチャーは、 py.exe (コンソールバージョン) と pyw.exe (GUI バージョン) の2つの実行可能ファイルを提供する。
  • ランチャーは、 .py (コンソール) と .pyw (GUI) の拡張子をもつファイルのハンドラとして登録される。
  • スクリプトを実行すると、ランチャーは Unix スタイルの #! (シェバング) を探す。そして python (システムデフォルトの Python)、 python2 (デフォルトの Python 2 リリース)、 python3 (デフォルトの Python 3 リリース) の実行可能ファイルを認識する。このバージョン指定の詳細レベルは、ユーザまたはマシン毎に簡単に変更できる。
  • 独立して使う場合、 py.exe コマンドランチャーは Python 対話型インタープリターを起動する。次の用途にコマンドラインスイッチがサポートされる。 py -2 が Python 2 を、 py -3 が Python 3 を、 py がデフォルトバージョンを起動する。

シンプルな使い方


ランチャーをインストールすると、 .py.pyw スクリプトファイルが関連付けされます。他に自分で設定しない限り、スクリプトはシステム上のデフォルトの Python を使って実行されます。そのため、特に変更は見られません。もしコンソールをよく使うなら、1つだけ設定を行った方が良いかもしれません。それは PATHEXT 環境変数 に .py を追加することで、スクリプトが別のコンソールで実行されないようにします。

Python 2 を使う必要があるスクリプトを指定するには、単に次の1行を
#!/usr/bin/env python2
そのスクリプトの最初の行に追加してください。(これは Unix 互換な書き方ですが、Unix 互換を必要としない場合は #!python2 でも構いません) 。

一方、Python 3 を使う必要があるスクリプトを指定したいなら、次の1行を最初の行に追加してください。
#!/usr/bin/env python3
また次のいずれかのコマンドを使って、Python インタープリターを起動できます。
# Python のデフォルトバージョン
py
# Python 2
py -2
# Python 3
py -3
実行するには、 py.exe の実行可能ファイルのパスが通っている必要があります。これはインストーラーの launchsys バージョンでは自動的に追加されますが、 launcher.msi のバージョンでは PATH に対して手動でインストールディレクトリ (C:\Program Files\Python Launcher) を追加する必要があります。

参考文献


次に紹介する python-dev メーリングリストのスレッドで重要な議論が行われています。

CPython 3.2.1 リリース

原文はこちら: CPython 3.2.1 Released

python-dev チームを代表して、リリースマネージャーを務める Georg BrandlCPython 3.2.1 の最終リリースを発表しました。Windows インストーラーと tar ボールが7月10日に提供されています。ぜひ、このリリースへアップグレードを検討してください。

What's New ドキュメントに 3.2 の新機能一覧が、ソースファイルに含まれる Misc/NEWS ファイルにバグ修正の一覧があります。

このリリースに関する問題、または何か他に問題を見つけたら http://bugs.python.org/ へ報告してください。

2011年7月7日木曜日

3.2.1 RC2 リリース

原文はこちら: 3.2.1 Release Candidate 2 Released

6月リリース に続いて、3.2.1 系の2番目のリリース候補 (RC2) が 提供されています 。5月15日にリリースされた最初のリリース候補から、40以上の問題を修正しました。3.2.1 の正式リリース前にもう1度確認する意味も含めて、みなさんのプロジェクトでこの RC2 をテストするのをお奨めします。

修正箇所

I/O
#1195 は修正するのに2、3年かかりましたが、 fgets を呼び出す前に clearerr を行うシンプルな修正により、 input() 内部で CTRL-D による sys.stdin.read() の中断に関する問題を解決しました。 io システムは、 #12175 において、 read()None を返すときに、その返り値の None と共に readall メソッドでクリーンアップするようにしました。そして、ファイルが開けないときは ValueError を発生させます。

#11272 は、RC2 で行われた修正内容ではありませんが、3.2.1 の重要な修正内容で、Windows 環境での文字列の後ろに続く \r に関する input() の修正です。この問題は何度も報告され、多くの人に影響を与えていました (disutils の upload コマンドなど) 。3.2.1 がうまく解決してくれることを望みます。
Windows
3.2.0 は、Windows 向けに os.symlink という新機能を追加しました。この機能は #12084 の問題からきていて、 os.stat は、Windows のシンボリックリンクを間違って評価するので、内部の様々な stat 関数の仕組みが修正されました。

あるユーザーが os.path.isdir が遅いことに気付きました。この原因は、前述した os.stat の修正によるもので、特にシンボリックリンクを評価するときに通常ファイルより2倍遅くなっていました。 os.path.isdir は、パフォーマンスのボトルネックにはならないとはいえ、インタープリター上で何度も呼び出されます。 GetFileAttributes を使う #11583 の修正により、ほんの少しだけ高速化されます。
subprocess
誤った引数で Popen オブジェクトを作成すると AttributeError が発生していましたが、その問題は #12085 で報告され、その報告者が修正しました。3.2.0 での変更に伴い、環境変数が空のとき、特に env 引数を Popen は正しく扱っていませんでした。 #12383 でその問題が報告され、すぐに修正されました。
その他
3.2.1 RC2 の全ての変更内容を知りたい方は、 チェンジログ をチェックアウトして いますぐダウンロード してください!

いつものように、どんな問題でも http://bugs.python.org へ見つけた問題を報告してください。私たちは、みんなの協力により品質の高い Python をリリースできることに感謝しています。

2011年6月15日水曜日

6月リリース - 2.6.7, 2.7.2, 3.1.4

原文はこちら: June Releases - 2.6.7, 2.7.2, 3.1.4

6月は、全てのアクティブなブランチでアップデートがリリースされるという Python にとって関心の集まる月となります。

2.6.7


Python 2.6.7 はソースリリースのみですが、3つのセキュリティの脆弱性への対策が行われました。現在、2.6 系はセキュリティモードであり、これらのリリースは、基本的には必要に応じて2013年10月まで、ソースのみ提供されます。もしバイナリインストーラーが必要なら、2.7 か 3.2 へアップグレードすることを検討してください。

2.6.7 は、以前このブログで紹介した urllib の脆弱性 の対策を含んだ最初のリリースです。さらに smtpd の DoS (課題 #9129 ) と SimpleHTTPServer.list_directory の XSS (課題 #11442 )の脆弱性も修正されています。

2.7.2


2.x 系の最後のマイナーバージョンである 2.7 は、2010年11月の 2.7.1 から 150 個以上のバグ修正が行われています。 2.7.2 のソースとバイナリインストーラーは、6月12日現在で利用できる状態にあり、2.6.7 の節で説明したセキュリティの脆弱性の修正も含まれています。

他にもたくさんのクラッシュする不具合が修正されました。例えば、別スレッドがメモリに関する変更を行ったときに Python が管理下にないメモリを不正利用してしまう不具合や、クラスから __abstractmethods__ を削除するとき、メモリマップファイルへ更新前のファイル長でアクセスしてしまうことなど、その他にもいくつか修正されました。

getpass のある修正が、CTRL-C と CTRL-Z の扱いに関してリグレッションを引き起こしていた問題が修正されました。 multiprocessing は、実行中に固まったような Windows サービスの扱いと multiprocessing.Pool ワーカーの終了時の競合状態への修正を含めた、たくさんの修正が行われています。 mmap は、 32 ビットビルドでも 4GB 以上のファイルサイズとオフセットを扱えるように修正されました。また、書き込みできないマップファイルへ書き込もうとしたときに、セグメンテーションフォールトではなく TypeError を発生させるようになりました。

全ての変更内容については 2.7.2 NEWS ファイル をご覧ください。

3.1.4


3.1.4 は 3.1.x 系の最後のバグ修正リリースです。3.2 へ移行するにつれて 3.1 はセキュリティモードに入ります。3.1.4 は2010年11月の 3.1.3 リリースから 100 個以上のバグ修正を含みます。2.7.2 と同様に、バイナリインストーラーが6月12日現在で利用できます。3.1.4 は、2.6.7 で説明したセキュリティ脆弱性の修正を含む最初の 3.x 系のリリースです。

3.1.4 は、オブジェクトを調べる __dir__ に関するいくつかの問題や、 os.statos.utime の Windows 環境の実装における2038年以降の日付の問題、たくさんの 64 ビットのクリーンアップの問題を修正しました。 io ライブラリは、データが読み込めなくて、他の場所で適切な例外が発生したときに None を返す変更がたくさん見られます。64 ビット Windows 環境での ctypes のコールバック引数が修正されて、クラッシュしないように改善されました。

全ての変更内容については 3.1.4 NEWS ファイル をご覧ください。

3.2.1


3.2.1 は、現在、リリース候補 (RC) の段階です。RC1 は既に完了し、すぐに RC2 がリリースされるでしょう。私たちは、ユーザが発見したどのような不具合にも対応できるように、3.2 RC を実際に試してくれる方へとても感謝しています。もしバグを発見したら bugs.python.org へ登録するようにしてください。

2011年5月24日火曜日

Python コアメンターシッププログラム

原文はこちら: The Python Core Mentorship Program

Jesse Noller は、最近 Python コアメンターシップ プログラムの設立を 発表しました 。このプログラムの背景にある想いは、学生や他プロジェクトの開発者を含めた幅広いプログラマに対して、メンター (指導者) として協力してくれる経験豊富な貢献者とやり取りして、Python コア開発を楽しんでもらえるように手を差し伸べることです。

貢献者の募集


メンターたちは経験のレベルに関わらず、貢献者たちとけんか腰で接さず快適な雰囲気で必要な情報を教えたり、質問に答えたりするのに協力します。貢献者は、関連メーリングリストの議論、バグトラッカー、Mercurial、コードレビュー、その他全てを含むプロジェクトに貢献するプロセス全体を通して助言を受けます。

早期の成功


このプログラムは既に成功を収め、その参加者は積極的にたくさんのパッチをコミットしています。さらに、メーリングリストで多方面から建設的な議論が行われ、多くの問題に対する正しい方向付けとなる道しるべになっています。

行動規範


このプログラムは、 ウェブサイト で行動規範を紹介しています。この行動規範は、多くの新たな貢献者が、メーリングリストや経験豊富な開発者とやり取りするときに、普通に抱くような不安や懸念を和らげることを目的としています。Jesse やその他のメンターたちは、このプログラムが Python コア開発の利益になるだけでなく、長期的には他のプロジェクトのモデルの1つにもなり得ることを期待しています。さらに Python の貢献者全体の多様性を高めるのにもつながることを望んでいます。

参加表明


このプログラムは メーリングリスト を通して行われ、分かりやすく簡潔な専用の ウェブサイト もあります。もしも、あなたが質問することからコア開発を始めてみたいと考えている。または、あなたが (Python コア開発も) 経験のある開発者であっても、他のメーリングリストへ投稿しようか気がかりな質問をもっているのなら、それはまたとない絶好の機会です。まずは質問することから始めてみましょう!

2011年5月20日金曜日

ポルトガル語、ドイツ語、韓国語、中国語 (繁体字) の翻訳

原文はこちら: Portuguese, German, Korean, and Traditional Chinese Translations

Python Insider の 翻訳プロジェクト は今も拡大を続けています! ポルトガル語, ドイツ語, 韓国語, 中国語 (繁体字) の翻訳ブログを立ち上げました。各言語のブログの翻訳者は、既に過去の記事の翻訳を進めています。他の翻訳ブログと同様に、これらの並列した翻訳ブログは、オリジナルの Python Insider の記事から少し遅れるかもしれません。

2011年5月14日土曜日

Python 3.3 で導入されるデバッグに役立つ faulthandler モジュール

原文はこちら: New faulthandler module in Python 3.3 helps debugging

プログラムが強制終了したり、固まったりしたことをユーザが報告する際にできることは、その状況の再現手順の概要とより詳細な情報を収集しようとすることだけです。信頼できるユーザーからの再現手順であっても、オペレーティングシステムやコンパイラといった環境の違いから、開発者として再現できないこともよくあります。運が良ければ、ユーザーがデバッグツールをインストールしてくれますが、誰かが同じ環境で詳細な情報を収集してくれるまで、ほとんどの時間を待っていなければなりません。

致命的なエラー


Python 3.3 で導入される新たなモジュール faulthandler は、この問題に役立ちます。 faulthandler は、セグメンテーションフォールト、ゼロ除算、処理の中断、バスエラーといった致命的なエラーのトレースバックをダンプする機能を提供します。Python の実行ファイルに対して -X faulthandler オプションを指定するか、もしくは環境変数 PYTHONFAULTHANDLER=1 を設定してから、 faulthandler.enable() を使ってアプリケーション内部で有効化します。出力結果は次のようになります。
Fatal Python error: Segmentation fault

Current thread 0x00007f7babc6b700:
  File "Lib/test/crashers/gc_inspection.py", line 29 in g
  File "Lib/test/crashers/gc_inspection.py", line 32 in <module>
Segmentation fault

タイムアウト


faulthandler は、 faulthandler.dump_tracebacks_later(timeout) を使って、タイムアウトした後にトレースバックをダンプすることもできます。そのタイマーを再起動するために再び呼び出すか、そのタイマーを停止するために faulthandler.cancel_dump_tracebacks_later() を呼び出します。出力結果は次のようになります。
Timeout (0:01:00)!
Current thread 0x00007f987d459700:
  File "Lib/test/crashers/infinite_loop_re.py", line 20 in <module>
timeout 秒毎にトレースバックをダンプするには repeat=True オプションを使ってください。または、そのプログラムが不安定な状態のときに、例えばファイルをフラッシュせずに、すぐに終了するには exit=True を使ってください。

ユーザシグナル


プログラムを実行しているホストへアクセスできるなら、 signal を受け取ったときに、トレースバックをダンプするシグナルハンドラをインストールするために faulthandler.register(signal) を使ってください。UNIX 上では、例えば、 SIGUSR1 シグナルを使えます。 kill -USR1 <pid> は、カレントのトレースバックをダンプします。この機能は Windows 上では使えません。出力結果は次のようになります。
Current thread 0x00007fdc3da74700:
  File "Lib/test/crashers/infinite_loop_re.py", line 19 in <module>
もう1つの方法は、プログラム内で明示的に faulthandler.dump_traceback() を呼び出します。

セキュリティの問題と出力ファイル


faulthandler は、セキュリティの理由からデフォルトで無効化されています。その主な理由は sys.stderr のファイルディスクリプタに保存して、そこへトレースバックを書き込むからです。もし sys.stderr がクローズされて、ファイルディスクリプタが再利用される場合、そのファイルディスクリプタはソケット、パイプ、重要なファイル、またはその他に使われる可能性があります。デフォルトでは、 faulthandler はトレースバックを sys.stderr へ書き込みますが、別のファイルも指定できます。詳細は faulthandler ドキュメント を参照してください。

古い Python バージョン向けのサードパーティモジュール


さらに faulthandler は、 PyPI 上で Python 2.5 から 3.2 を対象としたサードパーティーモジュールとしてメンテナンスされています。Python 3.3 のモジュールとサードパーティモジュール間での主な違いは dump_tracebacks_later() の実装です。Python 3.3 は、ロックのタイムアウトをもつスレッドを使うのに対して、サードパーティモジュールは SIGALRMalarm() を使います。

Python 3.3 の新機能であるロックのタイムアウトは、マイクロ秒単位の精度です。旧バージョンで使われる alarm() タイマーは、秒単位の精度です。さらに SIGALRM シグナルは、 EINTR エラーで失敗したカレントのシステムコールを中断させる可能性があります。

早期の成功


新たな faulthandler モジュールは、既に buildbot の競合状態を追跡するのに役立っています。このモジュールがあなたのプログラムにおいても役立つことを願っています。