このページの参照数 6180 回
リンク（徐々に増やします）
日本語のサイト
英語サイト
Zope関連
Pythonってどんな言語？
「プログラミング未経験の方」向けの説明
Pythonは数あるプログラミング言語の中で、入門者に優しく、奥の深い言語です。Pythonだけではできないこともたくさんありますが、習得したPython言語が不要になる日はまずこないでしょう。
なお、有名なマーフィーの法則に「教育用にも使えるものは、教育用にしか使えない」というものがありますが、このPython言語に関して言えば、その法則にはあてはまりません（実際、教育用としても実用としても使われているのですから）
欠点といえば、実行速度の遅さと、日本での知名度の低さ、でしょうか。
ともかく、「はじめてプログラミングを習ってみたい」なら、Pythonがお勧めです。
「他言語を経験された方」向けの説明
Pythonは、プログラミングの概念をすでにある程度理解された方にとっては、ものの２、３時間で習得できるお手軽な言語です。もしかしたら、前言語には無かった新しい視点が得られるかもしれません。
- ソースコードの見通しの良さ(可読性)を最重要視
Pythonの言語仕様の全てはここから始まります。他人がソースを読んだり、自分の過去のソースを読んだ時に「見通しが良い」ことは、すなわち改良／再利用を促進するのみならず、教育／習熟用にも利用でき、さらに非プログラマにもアピールしやすく、その結果、ユーザを増やすことにもつながります。ソースコードを読む／読ませることに特化した言語というのが、Pythonの最大の特徴だと思われます。
なお、この可読性に関しては、他の要素と矛盾することが多く、特に書きやすさ（記述性？）との矛盾は、「手軽で書きやすい言語」というスクリプト言語の特徴と思われる部分と相反するため、批判が多い特徴でもあります。
- C/C++言語に似た言語仕様
細部を見ていくと、C系言語のポリシーとはかなり異なるPythonですが、見かけ上はC系言語に近い文法構造／演算子／予約語を採用しています(特にC++に近い)。思想を言語仕様に反映させていまいちポピュラーにならなかった、Pythonの祖先であるABC言語の反省からこうなったものと思われますが、逆にC/C++言語系言語や、同じC系スクリプト言語であるPerlのユーザには違和感を与える結果になることもあるようです。
- インデントブロック(非フリーフォーマット)
C系言語の「当然の特徴」の一つが、インデント(字下げ)や改行などを読みやすい形に自由にデザインできる「フリーフォーマット」なのですが、Pythonでは｛｝(ブレース括弧)ではなくインデントの深さによってブロック構造を表現するため、フリーフォーマットではなくなってしまいました。
これは、ABC言語から受け継いだ重要な仕様ですが、その意図は最初に述べた「可読性」重視によるものです。しかし、特にクラッシックな非フリーフォーマット言語を経験してきている方々には、非フリーフォーマットというだけでなんだか「古臭くて使いにくい」という印象を与え、敬遠される結果になっているようです。実際に使い始めた人は、あまり気にならなくなるようですが、それでも、AWKで流行った「一行野郎」（コンソールに一行で入力できるスクリプト）で、あまり凝ったことが出来なくなったのは事実で、スマートさをモットーとするパワースクリプターにはやや不人気のようです。
- 文(statement)ベースの構文
多分プログラマに、フリーフォーマットより不人気であろう特徴は、この「文ベース」の構文でしょう。「式(expression)」をベースにしたC言語系プログラミングテクニックがほぼ壊滅的に使用不能になることは、その道で職人芸を発揮してきたプログラマ(C,C++,Perl,AWK,ICONなど)にとってはあまり面白いことでは無いでしょう。式ベースにすることによる可読性の低下防止と思われますが、好みの分かれるところでしょう。
- 型チェックのゆるやかな言語
Pythonには厳密には代入という概念は存在せず、全て名付け(Assignment)となっているため、変数型チェックの必要がありません。
そのため、一般のスクリプト言語やSmalltalk系オブジェクト指向言語と同じく、Pythonのオブジェクト型に対するチェックは(特にチェックルーチンを設けなければ)ありません。よって、多態性を実現するためにインターフェイスを独自に定義する必要はありません。
別段際立った特徴ではないのですが、クラス定義や使用方法などがC++やJavaに似ているため、違和感を覚える人があるようです。
- オブジェクト指向思想にこだわらないOOP言語
Pythonは最初からオブジェクト指向プログラミング言語(Object Oriented Programing Langage)として設計されていますが、オブジェクトは「オプションだ」と言い切られているように、オブジェクトを意識せずとも十分プログラミングは可能です。ただし、ver.1.6以降(実際はPython ver.2.x系のための改変なので、以後Python2と記述します)大幅な言語仕様の見直しが行われ、以前はオブジェクトでなかった数値などもオブジェクトとして再設計されたため、「完全なオブジェクト指向言語」になりつつあります。しかし、オブジェクトを意識せずともプログラミングできる基本は全く変わっていません。
※ver.3に向けて、型／クラスといった概念が整理され、propertyなどのオブジェクト指向プログラミング用のツールが少しずつ出揃ってきています。
- 少ない文法、多彩なデータ型
Perlの多彩な文法は魅力的で、クールなショートカットスクリプトを書くには非常に便利ですが、Pythonではあえてその魅力的な部分を捨てて、単純な文法構造に徹しています（理由はやはり可読性）
その代わり、ICONから譲り受けた多彩な組み込みデータ型や演算子が使用できます。Javaでは敬遠された演算子のオーバーロードは、C++式ではなく、Smalltalk式のメソッドフック実装という形でオブジェクト毎に設定できますので、シンプルな記述が可能となります（Javaの思想ではこの「演算子のオーバーロード」は「可読性の低下・難解・使用率の低さ」ゆえに忌避されているようですが、ほとんどのパッケージソースが閲覧可能なPythonでは、事実上あまり問題になっていないようです。とはいえ、パブリックなモジュールには、必要以上には使われていないのも事実ですが・・・）。なお、Python2では、組み込みデータ型の継承による拡張が可能となりましたので、データ型利用の自由度はさらに上がりました。
- 遅い実行速度
「改善されている」「マシンパワーが全体的に上がっているのでさして問題にならない」「生産効率のほうが重要だ」などといわれていますが、本質的に「人間に読みやすい、書きやすい」言語を目指したため、どうしてもコンパイラ言語のみならず、他のスクリプト言語や、下手すると実行コンパイルさえしない優秀なインタープリタ言語(PHPなど)よりもさらに遅かったりします。改善されているのは事実ですが、やはり他言語と比較して早くなることは、これからもまず無いでしょう。
- 少ない組み込み関数／豊富なライブラリモジュール
Python言語仕様とは少し異なりますが、ライブラリモジュールをインポートせずに使えるPythonの機能はごくわずかです。Cほど極端ではありませんが、例えば実行時の引数を調べることすら、sysというモジュールをインポートしないと使えません。さらに内訳をバラすなら、sysは「組み込みモジュール」として、処理系のコアと不可分に組み込まれているのに、わざわざ呼び出しが必要なのです。そもそも、「組み込みモジュール」なんて不思議なもの、他の言語にあるでしょうか？（標準、じゃないですよ）。これは、キーワードや組み込み関数を極力減らし、名前空間の衝突によるトラブルを回避した結果なのですが、他言語の経験者にはいかにも奇異に見えるかもしれません（いや、C経験者にはわかるかな？・・・でも、「組み込みモジュール」は理解不可能だろうなぁ・・・)
- ロング整数(多倍数整数)サポート
メモリの限り無限桁数を扱えるロング整数が、コアとしてサポートされています。その関係か、科学計算関連でPythonを使用される方は多いようです。
- 例外検出用文法のサポート
例外を捕らえる文法が、基本文法として取り入れられています。例外は組み込み例外以外にも自由に設定できるので、エラー検出以外にもプログラムに積極的に利用できます。例えばPythonではジャンプ構文が全面的に撤廃されていますので、多重ループから抜けるために例外文法を利用することなどが可能です。
- 日本語問題
現在、PyJUGの日本語環境をインストールすれば、UTF-8系Unicodeについては問題なく使えるのですが、S-JISとなると、内部でコード変換する必要がでてくるなど、やや面倒な処理が必要となります（Pythonはテキストだけでなくバイナリファイルも普通に処理できるので、フィルタなどはそちらで行うこともできますが、GUIを使うためにはコード変換が必須です）
※次期Python(2.4)より、本家の実装が日本語（及び、韓国語／中国語）をサポートするそうです。アジアにPythonが認知された結果なのか、あるいは本家Pythonコミュニティーがアジアの存在を認知したのか、いずれにせよ喜ばしいことです☆
- 明示的なselfポインタ
Pythonにはメソッドの外のクラスフィールド／インスタンスフィールドに対して暗示的にアクセスすることはできません。そのため、C++のthisやSmalltalkのselfにあたるポインタを「自分で設定し」「そこからアクセスする」必要があります。メソッドの第一引数は必ず所属オブジェクトのselfポインタになります。
- 強力なモジュール機能
ライブラリモジュールが充実していることはすでに述べましたが、自分でモジュールを作成することもPythonでは容易です。import文でパスの通った場所のファイル名を指定してやれば、そのファイルは指定された名前空間に導入されます。モジュールの作り方には何の制限もなく、ただ、ファイルの拡張子を.pyにすれば良いだけです。このことによって、プログラムのモジュール化や再利用が促進され、コーディングのコストが大幅に削減されます。また、モジュールをパッケージ化したり、モジュールの中から特定のオブジェクトのみをインポートしたり、さらにはモジュール導入の際にモジュール名とは別の名前空間で登録できたりします。
なおこの特徴は、Pascal系言語のModula-2から導入したそうです。Javaのモジュール／パッケージインポートに似ていますが、モジュールから手軽にオブジェクトを利用できるJavaと、あくまで名前空間の衝突を避けようとするPythonは実際にははっきりと異なりますので、両方を使うプログラマは注意が必要です。
- かっこが外せない？
AWK,Perl,Rubyなどでは、関数の後ろの括弧が、見かけ上明白な場合は括弧がはずせますが、Pythonでは外せません。これは、関数もすべてオブジェクトなので、括弧が無い場合、関数の適用ではなく、関数オブジェクトへの参照とみなされます。関数をオブジェクトとして扱うのが頻繁になるとこの特徴は非常に便利なのですが、普通はわずらわしいと思われる方も多いようです。これはPythonの思想を反映した仕様ですので、あきらめてください。
「マニアを自認する方」向け
ここでは、Pythonという言語をある程度見聞きして知っている方について、ややコアなPythonの話題を掲げます。
※注意：この項目の特徴に関しては、使用の際、十分注意が必要です。さらに、この項目に挙げられた特徴を使用せずとも、通常のプログラミングにはほとんど支障がありません。
- 関数型プログラミングをサポート
関数はキーワードではなくオブジェクト(ポインタ)として登録されます。そのため、変数やリストに代入(実際はassignment)して処理することも可能です。その結果、C++のようにクラス定義の外でメソッド定義することも可能です。また、関数として呼び出せるクラスインスタンスを定義することも可能です。
さらにPythonでは、制限付きながらlambda式が使用可能で、関数オブジェクトと合わせて関数型プログラミングが一応可能です(Pythonのポリシー上、Lispほど自由には使えませんが）
この機能を多用するとソースの可読性が落ちるため、コミュニティーの中にはlambda文およびその眷属の関数(apply,filter,map,reduce)の撤廃派がいるようですが、私としては、せめてモジュールでも良いので残しておいて欲しいと思います。
- メタクラスプロトコル
最初から装備されていたらしいですが、便利に使えるようになったのは、2.1以降です。クラスのクラスであるtypeを使って、動的にクラスを作るなどの操作が可能です。
- レキシカルスコープとクロージャの実装
関数の入れ子を作ると、入れ子の深度とスコープルールが一致するレキシカルスコープルールが、Python2ではより明確になりました。このため、クロージャの実装がより手軽になりました（多分・・・）
- イテレータ／ジェネレータ
Python2で導入されたyieldキーワードによって、クラスによるオブジェクト定義を行わずとも手軽にイテレータ／ジェネレータを作成できるようになりました。
- フィールド代入制限機構
Pythonでは、メソッドやフィールドの書き換えについて、ほとんど何の制限もありませんが、誤ってそういったものを書き換えないための保護策は、__setattr__組み込みメソッドによって実現されています。ただし「悪意ある」書き換えを保護する機能は、存在しません。
(ver.2.3.3現在、propertyオブジェクトを試験的に導入し、将来的にオブジェクトの構造や構成が見直される模様)
Rubyユーザの方へ
「オブジェクト指向スクリプト言語Ruby」に書かれている項目のうち、「文字列などの基本データ型はインスタンスではない」「本物のガーベージコレクタは無い」の２項目は消しておいて下さい。
現在Pythonの全てのデータは文字通りオブジェクト（インスタンス）であり、そのクラスを拡張することも、インスタンスから参照することも可能です（当たり前ですが、これはCで実装されていますので、Cコードで拡張クラスも書ける筈ですが、未確認です）。
あとは実行速度ですが、これは多分今でもRubyより遅いでしょう・・・（Pythonにも色々秘密兵器がありますが、まぁそれはおいといて）。
処理系の遅さについては、Perlの項では「なんとかなる」とご本人もおっしゃてることですし☆
さらにいえば、前述のとおりイテレータも完備されておりますし（当時はRubyにあってPythonにはなかった）お望みならLispっぽくlambdaも使えますし・・・
よりPerlっぽく書く（ダイレクトに正規表現やヒヤドキュメントを書くような）ならやはりRubyですが、特にPerlに思い入れもなく、SmalltalkよりC++のファジーなオブジェクト指向が好みならば、Pythonのほうがおすすめです（主観ですが(笑)）
目下の問題点
- 改定作業進行中の文法
現在、ver.3に向けてかなり大きな改変が行われています。
除法演算子の返り値やオブジェクト階層などは、これまでの拡張的改変と異なり、ものによっては過去のコードと互換性が失われる可能性が生まれるほど大きなものになります。
安定しない文法は、初心者入門用・教育用としての用途への支障をきたす恐れがあります。
言語をよりよいものにしようという考えは良いのですが、このあたりでどこか(ver.1.5.2のように)ドキュメント化しやすい安定バージョンを作ってほしいと思います。
おまけ
![[PukiWiki]](skin/modernskin/logo.png "[PukiWiki]"){kind=logo}
