Monthly Archives: December 2013

SQLite Integration 1.5 リリース

English version is available in SQLite Integration 1.5 released

SQLite Integrationを 1.5 をリリースしました。

  1. WordPress3.8 でのインストールと動作テストをしました。
  2. 新しく採用された管理画面に合うようにユーティリティのスタイルシートを変更しました。
  3. SQLite のコンパイルオプションを調べて、LIMIT 句つきの UPDATE や DELETE ができるかどうかをチェックするようにしました。
  4. SQLite と MySQL を切り替えて使えるオプションを追加しました。

前のバージョンでも WordPress3.8 が正常にインストールできることを報告してくれた方もいらっしゃいますが(ありがとうございます)、自分でもチェックしてみました。インストール、アップグレードともに問題がないようです。

ついでに、Subversion リポジトリの 3.9 アルファバージョンもチェックアウトしてみました。どうやら、mysqli や PDO ライブラリの採用はまだないようです。PHP 5.5 でも Notice が出ないように、E_DEPRECATED を抑制して、mysql ライブラリを継続して使っています。次期バージョンでも根本的な変更なしで、SQLite Integration が使える見込みです。

WordPress3.8 では、管理画面が新たなレスポンシブデザインに変更になりました。個別にプラグインとして開発されていた MP6 の成果が取り込まれているのです。モバイルデバイスでこんなところは見ないだろうと思いますが、スタイルシートを変更して、できるだけデザインを合わせました。ユーザのプロファイルページで、8つのカラーテーマが選択できるようになっていますので、選択されたものと同じ色を使うようにしました。あまりやる気がないので、やっつけだというのがバレバレだと思います。 🙂

新たなバージョンでは、SQLite ライブラリが、’ENABLE_UPDATE_DELETE_LIMIT’オプション付きでコンパイルされているかどうかをチェックするようにしました。このオプション付きなら、クエリの書き換えをせずに直接データベースに渡します。プラグインフォーラムを読んでいると、PHP 5.4 や 5.5 に移行した人が増えてきているようなので、SQLite ライブラリも変更になる可能性があり、複数行の values 句や、LIMIT をともなった UPDATE や DELETE 文が使えるようになっているかもしれないからです。もし、そうなら、データベース操作がより安全に、また、より速くなるはずです。

wp-config.php で、MySQL に簡単に切り替える方法はないか、という naillik 氏のコメントで、確かにそういう使い方もあるなぁ、と納得したので、それができるようにしました。新バージョンでは、wp-config.php で次のように定数を定義すれば、SQLite Integration の機能を停止できます。

"true"を"false"にするか、行を削除すると、SQLite に戻ります。最初に切り替えたときには、WordPress のインストーラが走るはずですから、通常どおりインストール作業をしてください。ただし、それぞれでの環境は引き継がれませんので注意してください。また、SQLite 用パッチをあてたプラグインを使っている場合、SQLite Integration が読み込まれていないと動かないものがあります。例によって動作保証はしませんので、好きなようにお使いください。

いくつかのファイルで、WordPress から呼ばれたかどうかをチェックするようにしました。実際には、外部から直接呼ばれても、サイトに害を与える動作はできません。が、サイトへの攻撃をする人たちは、脆弱性ありの(存在しない)プラグインのディレクトリや、脆弱性ありの(存在しない)phpファイルへのアクセスを繰り返します。このサイトも例外ではなくて、ありもしないファイルへの不正な GET や POST アクセスが毎日あります。パスカルの蠅のようにうんざりですが、蠅に蠅取り壺からの出口を示すこと(L. ヴィトゲンシュタイン)くらいのことはしておくことにしました。

Alex Almeda 氏のご協力に感謝します。プラグインに関するヒントを与えられました。

不具合やバグを発見したら、このサイトでコメントしていただいても、サポートフォーラムに投稿していただいてもかまいません。提案や感想も歓迎です。ありがとうございました。

SQLite Integration 1.5 released

Japanese version is available in SQLite Integration 1.5 リリース

SQLite Integration version 1.5 was released.

  1. WordPress3.8 installation and compatibility are tested.
  2. Changed the admin panel style sheet to fit the new responsive Admin panel.
  3. Added the code to check if the SQLite’s compile option about UPDATE or DELETE with LIMIT is enabled or not.
  4. Added the functionality to change the database between SQLite and MySQL.

Some of the users reported that they succeeded in installing WordPress3.8 with an older version (thanks for reporting), I checked myself if the latest version of WordPress works fine. I found no problems about installing or upgrading.

And I also checked out the 3.9 alpha version from the subversion repository. The alpha version doesn’t use PHP mysqli library nor PDO library but still use mysql library with the suppressing of E_DEPRECATED error reporting. This means that the next version of WordPress will continue to use the same database access method and you can use SQLite Integration without radical changes.

Admin panel of WordPress3.8 is changed to a new responsive design. It has included the former MP6 plugin developed separately. I don’t know if users want to see their database status with a mobile device or not, but I changed the style sheet to fit for it as much as I could. You can also select one of the eight color schemes on your profile panel. I add some stylesheet to use the same color that you select, though a little reluctantly. 🙂

The new version of the plugin checks if your SQLite library is compiled with the option ‘ENABLE_UPDATE_DELETE_LIMIT’. If it is, the plugin will not rewrite the UPDATE or DELETE with LIMIT query. Seeing the WordPress plugin forum, there’re more and more bloggers come to use PHP 5.4 or 5.5, which means their SQLite library is upgraded and the plugin has more chances to be able to use multiple values clause and UPDATE or DELETE with LIMIT clause. If this is the case, the database manipulation will be a little safer and faster.

I’ve got the comment from Mr/Ms naillik who wants to change the database with the directive in wp-config.php. I included this functionality in the current version of the plugin. If you want to use MySQL, add the next line in your wp-config.php (of course with correct MySQL settings).

This enables you to change the database from SQLite to MySQL. WordPress installation process will run for the first time, so you’ve got to install with MySQL. But notice that the post data or other environments settings are not migrated from one database to another. And most of the patched plugins require SQLite Integration. If you want to use SQLite again, change "true" to "false" or just delete that line. Try if you like, though I give no warranty at all as usual.

I added a few lines for some of the files to check if they are called from WordPress or not. In fact, even if they are called outside your site, they can do nothing to harm your site. But crackers are accessing the vulnerable (nonexistent) plugins’ directory, targeting the vulnerable (nonexistent) php files. This site is not an exception and has illegal GET or POST access every day. It’s really annoying like a Pascal’s fly. This is only to "shew the fly the way out of the fly-bottle"(L. Wittgenstein).

I’d like to express my thanks for Mr. Alex Almeda, who has given me some hints about the plugin.

When you notice malfunctioning or bug, I’ll appreciate receiving your reports or suggestions by the comment in this site or posting to the support forum. Thank you.

Python2.7 と Python3.3 を Windows で併用する

English version is not available.

Rilchiam! (Python2.x vs Python3.x)

Under which king, Bezonian? Speak or die!
——William Shakespeare, The Second Part of King Henry the Fourth
どの王様のことかな? 悪党め。言ってみろ、さもなきゃ、殺しちまうぞ。
——シェイクスピア, 『ヘンリー四世・第二部』

Python 2.x と 3.x のどちらを優先して学ぶのがいいのでしょう? これから Python を勉強しようという、私のような初心者にとって、これが問題になるのは、比較的新しい教本を読むと(*1)、3.x を中心として書かれているものが多いように感じますが、Google App Engine は 3.x に対応していなくて、Git をコンパイルしようと思ったら、Python 3.x ではエラーで止まり、レンタルサーバにインストールされている Python も 2.7 しかなくて、これでは実際に 3.x を使うチャンスなどないのではないか、という懸念があるからです。教本をざっと読んだ限りでは、後方互換性が一部損なわれているといっても、言語の構造については根本的な変更が加えられているわけではないので、2.x を学んで 3.x での変更点を学び直すのは(あるいは、その逆でも同じだけれど)、未知の外国語を勉強するほどの苦労はいらないだろうと思います。現代的なプログラミング言語は、ライブラリ(モジュール)が巨大になってきていて、言語のシンタックスを学んだだけでは何も作れないのが現実ですから、本当の勉強は、実は、シンタックスを学んだ後に始まります。Eclipse や Visual Studio といった開発環境は、Java Doc や、MSDN を簡単に参照できるようになっていますが、補完機能だけでは、未知のライブラリ関数については無力なので、ドキュメントの参照機能が必須だからでしょう。今から振り返ると、Unix のマニュアルページは、シンプルなだけに、よくできていました。

とはいえ、実際に Python 2.x 用のスクリプトを 3.x で動かしてみると、print 文や例外処理の変更だけではすまないエラーに遭遇するのも事実です。そうなると、両方を手元に置いておいて、動かしてみて違いを比べたいというのも人情でしょう。私自身、Debian には Python2.7 と 3.2 を、Windows には Python3.3 をインストールして使い分けていましたが、いちいちターミナルエミュレータで Debian マシンにログインするのが煩わしくなって、結局、Windows マシンに両方をインストールすることになりました。

たとえば、これが Debian GNU/Linux ならば、普通に両者をインストールして、update-alternatives コマンドで、どちらかをマスタに設定すれば併用に不自由はありません。でも、Windows では、どうすればよいのでしょうか。公式のドキュメント(最新日本語ドキュメントPython 2.7ja1 documentationおよびPython 3.3 documentation(翻訳中)(*2))は、Python 2.x 用と Python 3.x 用とが分かれていて、Python 2.x の方には、同じマシンに複数のバージョンをインストールする場合の注意がありません。これにはわけがあって、Python 3.3 をインストールすると、素晴らしく便利なユーティリティが付属していて(後述)、シェルに cmd.exe を使う限り、パスを通すくらいで、他にはほとんど何もしなくてもちゃんと使えるようになっているからです。

以下はその設定例と考え方ですが、MinGW の mintty を使っていたりするので、cmd.exe よりは少し面倒なことになっていますが、基本は共通です(*3)

  1. *1 O’Reillyの"Learning Python"第3版(2007年)で使われているコード例は Python 2.5 ベースで、3.0 でそのまま動かすとエラーになる部分を含んでいましたが、第4版(2009年)になると、3.0 を前提としたコードになって、2.6 では動かない部分について注釈を加えるというスタイルに変わりました。また、同じ著者による"Programming Python"第4版(2010年)では、"Python 2.X is no longer supported here(Python 2.x はもうサポートしない)"と言われています。
  2. 後に述べる py.exe のパートに入る直前まで翻訳されています。
  3. MinGW の mintty については別の投稿で書きましたので参考にしてください。

インストール

インストーラの指示に従ってインストールしてください。途中のオプション選択で、「Register Extension」のチェックを外しておけば、どちらを先にインストールしてもかまいません。

Windows 環境へのインストールについては、

が、基本的な情報を提供してくれます。また、公式ドキュメントからたどると、モジュールのインストール方法やインストール場所、その設定方法なども知ることができます。Windows の場合、インストール自体で困ることはないでしょう。ただ、オプション設定で、「Register Extension」を選択したかどうかによって、.py 拡張子と実行ファイルの関連付けが異なります。オプションにチェックした状態でインストールすると、.py 拡張子のファイルをダブルクリックしたときに、後にインストールした Python が起動するようになります。

もし、「Register Extension」をチェックしたいのであれば、後に述べる理由によてって、先に Python 2.x を、次に Python 3.x をインストールする方が、使い分けが断然楽になります。

IDLE を使ったり、python.exe を直接ダブルクリックするのではなく、シェルから python を起動する場合は、%PATH%環境変数で与えられたパスから python.exe が検索されます。ドキュメントに従って、%PATH% を設定しておきましょう。コマンドプロンプトや他のシェルで、python と打った時に起動してほしい方を先にします。ドキュメントでは、「autoexec.bat ファイル」と書かれたりしていますが、「コントロールパネル -> システムとセキュリティ -> システム -> システムの詳細設定」とたどって、「環境変数」を設定しましょう。

または、

となります。

インストール後の環境

さて、実行ファイルへのパスが通った状態を確認しておきましょう。%PATH% では、C:\Python27 が先にある設定です。

Python2.7.5 の場合(事情があって、32bit 版をインストールしてあります)。コマンドプロンプトで、python と入力して実行すると、下のようになります。

> python
Python 2.7.5 (default, May 15 2013, 22:43:36) [MSC v. 1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'c:\\Python27\\python27.zip', 'c:\\Python27\\DLLs', 'c:\\Python27\\lib', 'c:\\Python27\\lib\\plate-win', 'c:\\Python27\\lib\\lib-tk', 'c:\\Python27', 'c:\\Python27\\lib\\site-packages']
>>> sys.prefix
'C:\\Python27'
>>>

Python3.3.2 の場合は、フルパスを与える必要があります。

> C:\Python33\python
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v. 1600 64bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path
['', 'c:\\Python33\\python33.zip', 'c:\\Python33\\DLLs', 'c:\\Python33\\lib', 'c:\\Python33', 'c:\\Python33\\lib\\site-packages']
>>> sys.prefix
'C:\\Python33'
>>>

モジュールの検索は、sys.path に登録されたパスから探すことになっていますが、デフォルトのサーチパスがすでに設定されています。ドキュメントによると、デフォルトのサーチパス(たぶん、prefix から後の相対パス)は、ビルド時に設定されているということです。ドキュメントでは、この sys.path の値がどのように作られるかが説明されています。まとめると次のようになるようです。

  1. カレントディレクトリを自動的に登録する。最初の空文字列”がこれです。
  2. 環境変数PYTHONPATHがあれば、そこに指定されたディレクトリを登録する。
  3. レジストリにPythonPathエントリがあれば、そこで指定されたディレクトリを登録する。
  4. 環境変数PYTHONHOMEが設定されていれば、そこから、なければ、python.exeのあるディレクトリから、Lib\os.pyを特定し、PYTHONHOMEを推定して、必要なサブディレクトリをsys.pathに登録する。
  5. PYTHONHOMEもPYTHONPATHも特定できず、レジストリのエントリもない場合は、デフォルトの相対パスが使われる。
  6. モジュール検索パスに、拡張子 .pth のファイルがあれば、そこに書かれたパス(相対パスでも絶対パスでもよい)を、sys.path の最後に付け加える。

「レジストリの PythonPath エントリは常に読み込まれる」とのことです。実は、インストールオプションで「Register Extension」を外しておいても、Python のインストーラは、レジストリに PythonPath などの値を書込みます。その他、インストールフォルダの記録や、アンインストール時に使う情報なども書き込まれます。

調べてみると、HKEY_USERS と HKEY_CURRENT_USER に、それぞれ PythonPath のエントリがありました。

キー \HKEY_CURRENT_USER\Environment\Software\Python\PythonCore\2.7\PythonPath
設定値 C:\Python27\Lib;C:\Python27\DLLs;C:\Python27\Lib\lib-tk
キー \HKEY_CURRENT_USER\Environment\Software\Python\PythonCore\3.3\PythonPath
設定値 C:\Python33\Lib;C:\Python33\DLLs

これらの値とデフォルトの値が、それぞれの Python 起動時に読み込まれているということですね。

これを見ると、環境変数に、%PYTHONHOME% や %PYTHONPATH% があらためて設定されていなくても、実行ファイルが起動できれば、何の問題もなさそうです。

使い分け

上に書いたように %PATH% の設定がされていれば、Python2.7 は、通常どおり、python コマンドで起動できますから、Python3.3 をフルパスではなくて、起動することだけを考えればよさそうです。ところが、Windows のコマンドプロンプトなら、それでいいのですが、MinGW の mintty を使っていると、対話プロンプトが表示できません。仕様というか、使っている人はだれでも知っていることなのですが、まあそういうことになっているわけです。-i オプションをつけて起動すればよいのですが、オプションなしで起動しても、対話プロンプトになってほしいので、これが実現できるように、mintty の設定を後で例示します。

幸い、Python3.3 には、py.exe、pyw.exe という素敵なランチャが付属しているので、これを使って、起動を制御することにします。Python 3.x をインストールするときに、「Register Extension」をチェックしておくと、.py ファイルは py.exe と、.pyw ファイルは pyw.exe と関連付けがされるようになります。現在の実行ファイルの配置は次のようになっています。

C:\Python27\python.exe
C:\Python27\pythonw.exe
C:\Python33\python.exe
C:\Python33\pythonw.exe
C:\Python33\py.exe
C:\Python33\pyw.exe

cmd.exe を使う場合

Windows のコマンドプロンプトを使っての起動方法は以下のようになっています。

> python(w)             -> python2.7が起動する
> py(w) (-2)            -> python2.7が起動する
> py(w) -3              -> python3.3が起動する
> C:\Python33\python(w) -> python3.3が起動する

ほとんどこれで十分なのですが、「"py -3"でも長すぎる! 俺は"p3"で、python 3.3 を起動したいんだ」という場合は、C:\Python33 ディレクトリに、下のような p3.bat みたいなファイルを作っておけばお望みの動作ができます。

これで、下のように起動できます。

> p3

でも、こんな面倒なことをするよりは、py.exe という素敵なランチャを使うようにしましょう。

py.exe というランチャ

この py.exe というコマンドは、What’s New In Python 3.3Using Python on Windows に記述がありますが(日本語訳はWindows で Python を使うですが、ちょうど py.exe の説明から未訳となっています)、なかなかすぐれもので、バージョンを選ばずにどの Python でも起動できます。32bit、64bit も関係ありません。コマンドラインから起動するときは、上に書いたように、オプションをつけると、そのバージョンが起動できるのですが、メジャーバージョンだけでなく、マイナーバージョンまで指定できます。32bit 版と 64bit 版がインストールされていると、64bit 版が優先されますが、オプションに -32 をつけると、32bit バージョンが起動できます。

> py -2.5-32

として、起動すると、ちゃんと Python2.5 の 32bit バージョンを呼べるとのことですから、2.x を複数、3.x を複数インストールしてあっても使い分けができます。オプションなしで、起動すると、"the most recent version is used by default"(最も最近のバージョンがデフォルトで使われる)とのことですが、これは、新しいバージョンのほうが後にインストールされているはず、という前提のようで、必ずしもバージョン番号が大きいということではなくて、一番最後にインストールしたバージョンという意味のようです。

実は、インストール時に .py ファイルの関連付けをするように指定すると、この py.exe コマンドに割り当てられます。.pyw は、pyw.exe に割り当てられます。

このランチャがすごいのは、上のようにコマンドラインからオプションで起動を制御できるだけでなく、Python のソースファイルの先頭に shebang 行があると、それを読んで Python のバージョンを決定したり、設定ファイルや環境変数で制御したり、ということができるのです。ポータビリティがよくなり、Windows をあまり意識せずにプログラミングができるかもしれません。ただし、後で述べるように、Apache とともに、CGI として使うときには、環境が引き継がれないので、制限があります。

順番に見ていきましょう。

コマンドライン引数

> py --help

とすると、最初に py.exe のヘルプ、その後に python のヘルプが表示されます。コマンドラインで指定できるオプションは次のとおりです。

コマンドライン引数 意味
-2 最新の Python 2.x が起動
-3 最新の Python 3.x が起動
-X.Y 「メジャーバージョンX.マイナーバージョンY」の Python が起動
-X.Y-32 「メジャーバージョンX.マイナーバージョンY」で 32 bit バージョンの Python が起動

最後の、32 bit を指定するには、マイナーバージョンまでの指定が必要です。最初にハイフンと数字で始まる引数は py.exe に渡され、それ以降の引数は、起動される python.exe に渡されます。

shebang行

Unix では、スクリプトファイルの先頭に #! で始まる行を置いて、起動するコマンドを指定することができますが、これを shebang と呼びます(「シバン」「シェバン」どちらの読みもあるようです)。py.exe はこの行を解釈することができます。たとえば、下のような行があると、/usr/bin を飛ばして、最後の python と、そのオプションだけを見てくれるのです。

これを py.exe から実行すると、次のようになります。

> py test.py
Python 2.7.5

これを実行すると下のようになります。

> py test.py
Python 3.3.2

Unix なら当たり前とはいえ、Windows でこれができるというのは、なかなか賢いでしょう? ファイルの関連付けをしておくと、test.py をダブルクリック、またはコマンドラインから直接実行したときに同じ振る舞いをします。Unix のようなことができるのですね。py.exe が解釈できる shebang 行の例をあげておきます。

shebang 実行されるPython
#!/usr/bin/python C:\Python27\python.exe(デフォルトの python)
#!/usr/local/bin/python2 C:\Python27\python.exe
#!/usr/bin/python3 C:\Python33\python.exe
#!/usr/bin/env python C:\Python27\python.exe(デフォルトの python)
#!python C:\Python27\python.exe(デフォルトの python)
#!C:\Python33\python C:\Python33\python.exe

初期設定ファイル(py.ini)

py.exe の振る舞いを設定ファイルで制御することができます。設定ファイルの名前は、py.ini で、置ける場所は、py.exe が存在する場所と、ユーザのアプリケーション・データ・ディレクトリ(*1)です。両方に存在する場合は、ユーザのディレクトリの方が優先されます。

  1. Windows Vista、Windows 7 では、%USERPROFILE%\AppData\Local。Windows XP では、%USERPROFILE%\Local Settings\Application Data となります。
    Python 2 で以下のスクリプトを実行すると、自分のディレクトリを知ることができます。

初期設定ファイルには、次のように、[defaults]と[commands]を記述することができます。[defaults]は、デフォルトで起動する Pytyhon のバージョンを指定することができます(大文字小文字が区別されます)。[commands]は、上の shebang 行に、キーを書いておくと、値のとおりに展開されるようになります。

上の設定なら、デフォルトで、Python 3.3 の 32 bit バージョンが起動され、shebang 行に、#!mypython と書くと、#!C:\Python33\python.exe -foo -bar と書いてあるものと見なされます。

環境変数

Windows の環境変数で、デフォルトの設定をすることもできます。この設定は、初期設定ファイルの設定を上書きします。

ドキュメント

上のリンク以外に、作者の Mark Hammond 氏と Martin v. Lowis 氏によるPEP 397があって、おそらく最も詳しい仕様の説明となっていますので、一読をお勧めします。この文書で使い方はすべて理解できると思いますが、日本語訳が見つからなかったので、翻訳を作りました。->http://dogwood.skr.jp/tmp/pep-0379-ja.txt

pydoc をコマンドラインで読む

IDLE を使っていると、F1 でオンラインドキュメントを参照できますが、通常のインストールなら、ローカルにもドキュメントがあります。この py.exe を使って、ドキュメントをコマンドラインで参照するための、バッチファイルを作ってみましょう。ファイル名は、pydoc.bat と pydoc3.bat としてありますが、何でもかまいません。C:\Python27 と C:\Python33 にパスが通っていますから、そこに置いてもいいし、他の場所でもかまいません。必要なら、@SETLOCALの後に環境変数を定義することもできます。

コマンドプロンプで下のように使います。

> pydoc sys      --> ビルトインモジュール sys のドキュメントを読む(ページャにmoreが使われます)
> pydoc -k print --> print ステートメント(関数)を含むドキュメントを列挙する
> pydoc -p 8080  --> ポート番号8080でサーバを開く http://localhost:8080 でアクセスできます
> pydoc -w print --> printステートメント(関数)のドキュメントを、print.htmlとしてカレントディレクトリに書きだす
--- 下の2つは、Python2.7 と Python3.3 で異なるオプションです ---
> pydoc -g       --> TCL/TKの検索窓を開く
> pydoc3 -b      --> ブラウザでドキュメントの検索ページを開く

デスクトップに置いてダブルクリックすると、シェルが即座に終了してしまうので、cmd.exe /K を%PY%の前に追加すれば、ウインドウをキープできますが、オプションが自在に指定できないので、お勧めしません。ドキュメントに従う限りでは、Python27(33)/Lib/pydoc.py をダブルクリックすれば、上のバッチファイルと同じコマンドラインになるはずですが、やはりシェルが終了と同時にウインドウが閉じてしまうような気がします。ショートカットを作って、オプション -g や -b を固定にするというような使い方もできると思いますが、そうすると、ウインドウが逆に閉じないのではないでしょうか(試してません)。いろいろ試して、お好きな設定を発見してください。

mintty を使う場合

MinGW の mintty は、対話モードのアプリケーションがうまく扱えません。対話モードで使いたい場合は、MinGW の mintty で対話モード、ついでに vim 設定をご覧ください。

mintty の設定ページで説明したとおり、winpty の console.exe を使って bash.exe を起動する場合、基本的に何の設定も必要ないと思いますが、タイプ量が多くなるものについての .bashrc 例です。pydoc.py は、それぞれ shebang があるので、そのままファイルを指定すれば起動できます。。3.3 の方は、デフォルトでないので、実行ファイルを指定します。py.exe や pyw.exe は普通に動作しますのでそのままでいいでしょう。IDLE はスタートメニューから起動するのが面倒な人向けです。

console.exe を個別のアプリケーション毎に使う使う場合の、エイリアス例です。

console.exe は、パスの通ったディレクトリにインストールすると思いますので、実際は、フルパスは必要ありません。pydoc 関連は対話モードではないので、上の例と同じです。前のセクションでも述べましたが、これで、コマンドラインで、

$ pydoc sys | less

などとすると、ドキュメントを読むことができます(この場合はページャを指定する必要があります)。pydocw と pydocw3 では、規定のブラウザで文書を読むことになりますが、2.x と 3.x では、pydoc のオプションが違っています。Python 2.x の TCL/TK を使った検索窓は、3.3 ではなくなってしまったようです。コマンドラインで、"pydoc -k <keyword>"して検索すればいいのですが、ブラウザで該当箇所に飛ぶ手段がありません。ブラウザを起動してから、検索ボックスで検索するという順番になってしまったようです。コマンドラインの方が楽かもしれませんね。また、残念ならが、オンラインのドキュメントを指定するオプションが存在しないようです。IDLE のヘルプは、オンラインドキュメントを参照するので、これを起動するモジュールがどこかにあるはずだと思いますが…現状は、ssh でリモートのサーバに接続し、vim を起動してコーディングしながら、マニュアルを参照し、また vim に戻るみたいな使い方ができるという程度ですね。初心者の私としては、まだ Eclipse の PyDev を使うほど大きなプログラムは書けないので、vim の補完とこのマニュアルで十分なのです。

なお、IDLE の設定ファイルは、ユーザのホームディレクトリの .idlerc に入ります。Windows と MinGW 環境で別になっている場合は、それぞれのホームディレクトリに作成されます。

winpty を使いたくない場合は、明示的にオプションをつける必要があります。バージョンを指定する引数は、第一引数でなければならないので、エイリアスで、’py -i’としてしまうと、バージョンの指定の引数が python.exe に渡ってしまいます。このため、対話モードで起動したいときには、-i オプションをつけなければなりません。

$ py -i
$ py -3 -i
$ python -i
$ /C/Python33/python -i

XAMPP 1.8.3 で Python

XAMPP for Windows 1.8.2 がリリースされているので、入れ替えようと思ったら、1.8.3 がダウンロードできるようになっています。ページトップには、「XAMPP新バージョン 1.8.2 をリリースしました!」となっているのですが、1.8.3 はリリース版ではないということでしょうか? このバージョンから、Windows 2000、XP、2003 をサポートがなくなっているようです。 よくわかりませんが、ポータブル版を入れました。それぞれのバージョンは下のようになっています。1.8.2 との違いは、MySQL と PHP のバージョンだけです。ついに mysql ドライバ非推奨の環境に突入ですね。

ソフトウェア バージョン
Apaceh 2.4.4
MySQL 5.6.11
PHP 5.5.3
Tomcat 7.0.42
Strawberry Perl 5.16.3.1

いつの間にか、ポータブル版でも Tomcat と Perl が含まれるようになっていました(いらないのですが…)。PHP が 5.5 になりましたので、WordPress を DEBUG モードで動かすと、log がとんでもないことになりそうです。bitnamiがライブラリを提供することになったらしく、WordPress、Joomla!、Drupal のインストールリンクが追加されていました。

CGI として使う

インストールした先の Apache 設定ファイル(\xampp\apache\conf\httpd.conf)に、拡張子 .py を cgi script として登録します。

お好みで、DrectoryIndex に index.py を追加してください。\xampp\htdocs 以下に test.py を作って実験してみます。Python を Web 上で使うには HOWTOを参照。

ブラウザで、http://localhost/test.py にアクセスすると、’Hello, Python 2.7 was here!’ が見えるはずです。cgi として動かすスクリプトファイルで使える shebang 行は次のとおり。py.exe は -3 を指定しても同じ動作になります。Apache が読むので、py.exe 単体で使える「仮想コマンド」は、残念ながら利用できません。オプションなしの py.exe は、環境変数を設定すれば動作するかもしれませんが、どちらにしろ、コマンドプロンプトが開いてしまうので、使えないでしょう。これは、py.exe の仕様上、他のプロセスから実行されることは考慮していないので、仕方ありません。

shebang 結果
#! python OK 環境変数%PATH%で最初に見つかったpython.exeが起動
#! C:\Pytho27\python OK
#! py -2 OKだが、コマンドプロンプトのウィンドウが開く
#! C:\Python33\py -2 上と同じ
#! py コマンドプロンプトのウィンドウが開き、入力待ち、というか、プロセスが死ぬ
#! C:\Python33\py 上と同じ
#! /usr/bin/python Internal Server Error

mod_wsgiを使う場合

【2014-02-21 追記】

以前は、

modwsgiで配布しているバイナリは、そのままでは XAMPP 1.8.3 の Apache が読み込めません(起動に失敗します)。

と書きましたが、code.google.com では、Windows 用バイナリの配布をやめたようです。かわりに、Unofficial Windows Binaries for Python Extension Packagesが、VC 10 と VC 11 でコンパイルしたバイナリを配布しています。XAMPP 1.8.3 の Apache は、VC 11 でコンパイルされていますから、VC 11 用のバイナリを使うと、ちゃんと動かせるようになりました。

インストール、および設定は、code.google.com のページで読むことができますが、簡単なところだけ採録しておきます。

  1. アーカイブに含まれる mod_wsgi.so を、apache/modules ディレクトリにコピーする。
  2. apache/conf/httpd.conf に LoadModule ディレクティブを追加する。
  3. apache/conf/extra/httpd-vhosts.conf でバーチャルホストの設定をする。
  4. C:\Windows\system32\drivers\etc\hosts ファイルにバーチャルホストのアドレスを追加する。

"NameVirtualHost *:80"は必要なくなりました。

これで、http://localhost.python.com/myapp にブラウザでアクセスし、"Python was here!"と表示されれば成功です。

副作用

Notepad++

Python 2.7.5 をインストールすると、notepad++ のプラグイン Python Script が動作不良になります。また、この Python Script に依存する Emmet も動作しなくなってしまいます。プラグインに付属の python27.dll のバージョンが、インストールされたものと一致しないようで、モジュールの読み込みに失敗しているようです。

notepad++ のインストールディレクトリにある python27.dll を削除すれば、インストールした Python を自動的に使うようになります。なお、64 bit 版の Python 2.x では動作しませんでした。

Vim

vim orgで配布されている Vim7.4 は、Python のサポートが外されていて、IME も使えないので、transparency パッチだけを使い、Python と IME を有効にして、Visual Studio で 32bit 版と 64bit 版をコンパイルし直しましたが、32bit 版 vim では、64bit 版の pythonX.Y.dll を読み込めず、64bit 版 vim では、32bit 版の pythonX.Y.dll を読み込めません。vim の実行ファイルに合わせた Python をインストールしろということですね。