カテゴリー:Python

ASCII「デジタル用語辞典」の”Python”

2009年2月20日 (金)

ネットサーフィンをしていて、ASCIIの「デジタル用語辞典」中のPythonページに行き着いた。そこには、次のように書かれている。

ぱいそん 【Python】
Guido van Rossum氏が1990年に開発したスクリプト言語。プログラムをモジュール化して、他の言語で作成したものを含む他のプログラムに組み込んで利用することが容易であるという特徴を持つ。欧米では人気の高い言語だが、日本語を扱う仕組みを完備していないため、日本での人気は欧米ほどではない。 (C)デジタル用語辞典

ここに書いてあるよに、日本でのPython言語の人気は欧米ほどではない。どころか、全然人気の無い言語と思う。出版されている解説本の数を見る限り、人気はRuby、PHPよりずっと下のレベルだ。

上記解説では、Pythonが日本で人気の無い主な原因を「日本語を扱う仕組みを完備していないため」としているが、それは違う。UNICODEベースでプログラミングすれば、日本語の問題は全く発生しない。Python言語によるWebアプリケーションフレームワークのTurboGearsでWebアプリを開発したことがあるが、日本語の問題での苦労は全く無かった。だから、上記のこの記述は誤り、と私は思う。

最大の問題は、ドキュメントだと私は思っている。まず、日本語ドキュメントが少ない。これだけで日本では人気は無くなる。しかし英語のドキュメントは多い。Pythonの特徴として英語のドキュメントの豊富さを挙げる人もいるくらいだ。ただ私の意見では、ドキュメントのレベルが低い。Javaのドキュメントのレベルは高いが、その半分のレベルも行っていない。求めていることがドキュメントに書いていない、なってことは日常茶飯。そのときは先ずは情報をネットで探し(たいてい英語だが)、それで駄目ならソースを見ることになる。

また上記では、Pythonの主な特徴として「プログラムをモジュール化して、他の言語で作成したものを含む他のプログラムに組み込んで利用することが容易である」と書いてある。確かにこれは大きな特徴だが、もっと大きな特徴があると私は思う。それは、簡潔でハイレベルの記述力、だ。複雑なロジックを簡潔に記述できる能力は、言語の中でPythonはトップクラス、と私は思う。だから、Google社の社内開発言語としてPythonがオーソライズされたのだろう。PythonはJava以上に能力のある言語、と私は思っている。

Pythonは空白がお嫌い

2007年6月29日 (金)

PythonによるWEBアプリケーションフレームワークのTurboGearsは先月のバージョン1.0.2.2からPython2.5対応になった。それより前のバージョンはPython2.4。待ち望んでいたPython2.5対応なので早速TurboGears1.0.2.2をWindows環境にインストールした。もちろんPythonはバージョン2.5である。

何の問題もなくインストールは終了し、早速TurboGearsのコマンド
> tg-admin quickstart
を実行したが

Cannot find Python executable C:\Program

のエラーメッセージが表示され実行できない。Python実行プログラムが見付からない、とのたまう。Windows環境にはPython2.4と2.5が両方入っていたので、念のため2.4を削除してPython2.5のみとして実行したが同じエラーメッセージが表示される。

いろいろ試行錯誤して気が付いた。問題は \Python25\Scripts\tg-admin-script.py の1行目だった。私のWindows環境ではPython2.5は
C:\Program Files\Python25\
ディレクトリ下に存在している。なので、インストールされた上記tg-admin-script.pyの1行目は
#!”C:\Program Files\Python25\python.exe”
となっている。これが問題だった。これを
#!”C:\progra~1\Python25\python.exe”
と、空白を含まないパスにしたところ、正常に動作した。

他のスクリプトも調べたところ、nosetests-script.pyも同じだったので空白を含まないPythonのパスを指定するよう修正した。

あるPython入門書には、「Pythonはデフォルトディレクトリ(C:\直下)にインストールしたほうが良いよ。」と書いてあったが、なるほど、C:\直下ではなく C:\Program Files\下にインストールするとこのようなことが起こるのだ。

しかしPythonをC:\ の直下にインストールしたとしてもうまく行かない類似の事例を発見した。

環境変数PYTHONPATHも空白を含んではいけないのだ。開発ツールKomodoを評価のためインストールし、デバッグの調査のためリモートデバッグを行おうとした。そのKomodoリモートデバッグ用モジュールパスを環境変数PYTHONPATHに設定しなければならない。設定したのだがどうにもリモートデバッグは動かなかった。原因は、Komodoをインストールしたディレクトリの下のほうに空白を含むディレクトリがあり、それが原因で動かなかったのだ。パスをダブルクオーテーションで囲ってもNG。パスは(DOS時代の)ショートパスで指定しなければならない。これはKomodoをC:\直下にインストールしたとしても起こる問題だ。

結局、Pythonは空白がお嫌い、ということがわかった一件だった。

Python本表紙、または蛇女

2007年6月13日 (水)

私はいまPython言語に興味を持ち、仕事の一部に使用し始めたところである。この言語の名称であるPythonは、その開発者がBBCの番組「モンティ・パイソン」のファンであることから命名されたらしい。そしてPythonとは、ニシキヘビのことである。

先日さるブログで、「Python本の表紙はたいてい蛇が描かれていて気持ち悪いので買う気がしない」という記事を読んだ。(URLは不明。)私もPython本の表紙はすこし気になっていたので、調べてみた。そもそも人間が蛇を嫌がるのは、人間の古い脳にこの情報が刻み込まれているから、という話を聞いたことがある。太古の時代の記憶がよみがえるのか。以下、私の持っている主なPython本の表紙についての調査である。

1.速効!Pythonプログラミング
表紙右上に、ちょっと下手な蛇のイラストが描かれている。蛇はそれだけか、と思ったら違った。表紙背景の全面の模様は、模様ではなく蛇のウロコの拡大写真だった。そう思うと少々気持ち悪い。
内容としては、私はPython入門書のなかで現在では一番良い本、と思う。

2.TurboGears×Python
蛇はまったく描かれていないデザインの表紙である。
内容は少し物足りない。この本を読んだだけではTurboGearsは使えるようにはならない。まあ、薄い本なので情報量の少なさは止むを得ないとは思うが。

3.Pythonプログラミング入門
蛇関連では、ちょっと可愛い蛇のイラストがあるのみである。
内容は、Tkinterの記述の多いのが特徴である。私はTkinterは使用するつもりはないのでこの本を読んでもあまりメリットはなかったが。

4.みんなのPython
Python2.4のマスコット蛇に似た蛇のイラストが小さく描かれている。

5.初めてのPython
O’Reillyの本の通例の如く、表紙には動物が描かれている。なんとネズミ。ニシキヘビ(Python)の餌食になるであろうネズミがなぜ表紙なのか、理解不能である。
対応バージョンは少し古いし700ページの厚さだが内容はすばらしい。私はまだすべては読んでいないが、Pythonで仕事をするには精読しなければならない本と思う。

6.Pythonクィックリファレンス
生々しい蛇の写真。かなり気味が悪い。

7.IronPythonの世界
Iron Pythonという言葉どおりのメタリックの蛇がとぐろを巻いている。かなりリアルで気持ち悪い。
ちなみに.NET上のPython処理系であるIronPythonの本である。私は.NETプログラマではないのできちんとは読んでいない。

8.実践Python 文字列操作からWebアプリケーション開発まで
どこにも蛇は描かれていない。眼鏡をかけてちょっと痩せ型の若い女性のイラストが大きく描かれている。表情はなんとなく生気に欠け、そう思ってみると蛇女に見えてくる。。。

「JavaからRubyへ」を読んで

2007年6月11日 (月)

JavaからRubyへ ―マネージャのための実践移行ガイドを読んだ。これは題名のとおりJavaからRubyへの移行を強く勧める本。前半はJavaよりRubyがいかに開発効率が高いかが述べられ、後半は会社組織においてJavaからRubyへの移行を阻害する勢力への対応戦略が述べられている。その後半で、このブログの前回記事のJRubyそしてJython中のメインテーマのJRubyについて詳細に記述されているのには驚いた。共時性か。

私はひとりでソフトウェア開発をしているので、この本の後半は興味は無い。開発言語・フレームワークの決定権は私だからだ。前半の、JavaよりRubyがいかに優れているか、を興味深く読んだ。

ある動的言語(TCL,REXX,Python,Perl)と静的言語(Java,C++,C)の生産性を比較した研究報告によれば、なんと一番生産性の劣る言語はJavaで、最も高いのはPython。そしてその生産性は3倍違っていた、とのこと。どのような条件でJavaが最低だったのか知りたくその報告のURLにアクセスしてみたがアクセスできなかったのは残念である。

その生産性の悪さのひとつの原因として、かのJavaの神様Martin Fowler氏は、Javaフレームワークはアプリの本質の複雑性とは無関係の偶発的複雑性への対応を持ち込みすぎている、と述べているとか。確かにEJBのとてつもない複雑性はその例だろう。だいたい、EJBは分散環境でのWEBアプリに適している、と教科書には書いてあるが、分散環境なんて世界レベルの巨大システム以外には無用の長物だ。

そして著者は、「軽量フレームワーク」を一般的に構成するSpring,Hibernateの学習の困難さにも言及している。そう、私もこれらはちょっと本を読んだだけで、使用する気にはなれなかった。必要時はSeasarを使用するつもりだった。

そして著者は、WEBアプリ開発にはRubyによる開発フレームワークであるRuby On Railsの開発効率がいかに高いか、を実例を挙げて熱く語っている。その開発効率の高さの主要因は、コーディングの少なさ、と。バグはコーディング量に比例する、とのこと。

確かに私も、JavaによるWEBアプリ開発では、Strutsを使用した際にコーディングの量の多さにはうんざりした。そしてパターン化できる部分は、Javaソースコードのジェネレータを作成し自動生成させたものだ。

なるほど、Javaの開発効率の悪さはわかった。私がなんとなく感じていたとおりだ。そして著者によれば、実行速度もRubyのほうが速い場合もあるとか。これは意外だ。私は通常の(Cによる)Ruby実行環境は遅いもの、と思い込んでいたからだ。もしRubyがPythonレベルの実行速度なら、Rubyが遅いと書いたこのブログ中での各記事を訂正しなければならない。

ただ私は、Ruby On Railsにはすぐには飛びつくつもりはない。PythonでRuby On Rails類似のフレームワークであるTurboGearsと、ほとんど日本語情報は無いがPylonsで小規模WEBアプリを組んでみるつもりだ。その後にRuby On Railsを試してみて、どれが最も開発効率が高いか、結論を出すつもりだ。

JRubyそしてJython

2007年6月9日 (土)

Java実行環境のJavaVM(Java Virtual Machine)は、コンパイルされたJava中間コードを実行する環境である。ということは、ソースコードがJavaである必要はない。他言語のソースプログラムをJava中間コードにコンパイルできれば、それはJavaVMで実行できる。

そのようなソフトのひとつにJRubyがある。これは、Ruby言語インタープリタのJavaによる実装である。私はRubyは言語を少々勉強しただけなので、JRubyの存在は最近始めて知った。

JRubyによれば、6月2日にJRuby 1.0.0RC3がリリースされた。バージョン1.0の直前版の位置付けのようだ。

JRubyは、マイコミジャーナルの記事Java + RubyのJRuby - EJBからSwingまでRubyからJavaを使い倒すくに詳しく述べられている。その特徴は、次のとおり述べられている。

1.Rubyの言語仕様に準拠している:
Ruby1.8.5を元に、一部未実装や問題がある機能もあるものの、言語仕様を非常に互換性高く実装している。またRubyの標準ライブラリやgems (Rubyのライブラリなどをインストールするためのツール)についてもほとんどが含まれており、Rubyのプログラムの多くがJRuby上で正常に動作する

2.JVM上で動作する:
JRuby自体は100%Javaで実装された処理系である。したがって、実行するためにはJavaVMがあればよいため、Javaが動作する環境ならどこでもRubyプログラムを動かすことができる(コラム「プラットフォームとしてのJava」参照)

3.Javaプログラムと連携できる:
JRubyを使えば、Rubyで書いたプログラムからJavaのオブジェクトを利用したり、逆にJavaプログラムからRubyのスクリプトを実行したりすることができる

またその実行速度は、@ITの記事「本家Rubyより速い」、JRuby開発者に聞くによれば、そのタイトルの如く、Cで実装された通常のRuby実行環境より速いそうだ。

上記のJRubyの特徴は、想定の範囲内である。速度についても、私の想像どおりだった。RubyやPerlのように実行時にソースコードを解釈して実行するインタープリタの速度が遅いのは当然であり、スピードアップにも限界がある。それを、事前にJava中間言語にコンパイルさえしておけば、最適化や高速実行の研究成果が充分に反映されているJavaVMでの実行が速いのは当然、と思っていたからだった。

さらにJRubyは、最終的にRuby On Railsも完全に動作するようになるらしい。このメリットは大きい。最も効率良くWEBアプリを開発できるフレームワークと評判のRuby On RailsがJRubyで動くことで、その欠点の実行速度の遅さが克服できる。

翻って、PythonのJavaによる実装であるJythonは開発が遅い。この数年開発が止まっていたようだが今年の2月ころからまたすこしづつ動き出しているようだ。ただ、いまだにPython2.2レベルだ。最新のPython2.5対応はだいぶ先だろう。

通常のPython実行環境ではなくわざわざJythonを使うメリットはあるのだろうか。私はJRubyほどは存在意義が無いように思う。というのは、通常のPythonは実行速度が充分に速いので、実行速度の点でJythonを使用するメリットは無い。せいぜい、JRubyの特徴の「3」の、Javaクラスとの連携だろう。しかし、それに大きな需要があるとは思わない。JavaクラスをPythonからコントロールするメリットが思い浮かばない。せいぜい、スタンドアローンアプリで画面をJavaのSwingやSWTで構築しそれをJythonから制御する、くらいか。それも、JythonがPython2.4はサポートしてくれないと使いにくいだろう。

結局、通常のRuby実行環境が遅いことがJRubyの将来を明るいものにしている、というちょっと皮肉な現象かもしれない。

 

QLOOK ANALYTICS