Pythonへの誤解

誤解していませんか？

tags:python, column
created:2007-02-05T20:24:24

ある特徴がデメリットというのは誤解。

目次

「インデント強制」はプログラマの自由を奪う？

確かに不自由な事にはまれに遭遇します。

ぱっと貼り付けて仮に実行とかワンライナー記述ができなかったり。

これは、やってみるしかないでしょうね。 やってみれば、変則的な記述の時しか 不自由を感じないことがわかっていただけると思います。

ぱっと貼り付けたコードを整形し忘れたまま コミットしちゃったといったことありませんか？

ちゃんと読みやすいコード書くように心がけている人は、 「読みやすく記述するには」と考えるたり整形する手間を必要とします。

しかしこの制約のおかげで深く考えなくてもよくなり 周囲への周知などの手間が省け省力化に つながることが実感できると思います。

多少の不自由から開放されるメリットよりも、 コードの可読性が自然と確保されるというのは 大きなメリットだと思います。

「self記述省略不可」はOOPでないから？

OOPでなかったころの仕様を引きずっているというのは誤解です。

「self記述省略不可」という制約をなくそうと思えば 言語開発側からすれば簡単なこと。

ランタイム内でメソッド名からインスタンスへの逆引き辞書を用意すれば すぐに実現できるんじゃなかろうかと思う私は甘いですか？

あえて残しているというのが正しい理解だと思います。

例えば、もしselfが省略可能な場合の記述

class Hoge(xrcMainFrame):
  def test(self):
    widget = FindWindowByID(id1)

とselfが省略できない場合の記述

class Hoge(xrcMainFrame):
  def test(self):
    widget = self.FindWindowByID(id1)

という場合、双方で「FindWindowByID」という名称が 定義されていないというエラーが出たとき、

２つの状況それぞれであなたはどうやってエラーを解消しますか？

前者の場合:
  1. グローバル関数かクラスメソッドかを判定。
  2. Hogeクラスまたは親クラスに類似する定義がないか探す
後者の場合：
  1. Hogeクラスまたは親クラスに類似する定義がないか探す

後者ならば１ステップ省けますね？ しかもグローバル関数を探し当てるには エラー箇所の名前空間に影響している ファイルを一通り探さなければならないですね。

注釈

だからPythonistaは

from hoge import *

という記述を嫌います。

「self記述省略を可」と「self記述省略不可」による それぞれのメリット・デメリットは以下の点が主なものでしょうか。

self記述の省略 メリット デメリット
可能 記述がシンプル グローバル関数か そうでないか わかりにくい。
不可能 クラスまたは親クラス に所属しているのが 明示される。 記述がたいへん

あなたが面倒と思うのはどちらでしょう。

  • 「self.」をタイプするのを面倒と感じる。
  • 「名前」の所属先を探すのを面倒と感じる。

「思考ノイズ」が前者と後者を比較して後者の方が大きいと私は感じます。 ですので、前者の面倒は指が慣れれば思考ノイズにならなくなります。

ただし、グローバルファンクション名をすべて記憶している方なら

このファンクション名に見覚えが無いからこのクラスのメソッドだな

という判断が瞬時につくので「思考ノイズ」にならないのかもしれませんが。

また、

省略が可能なだけで所属クラスを明示したければ
明示することができるじゃないか？

といった意見もあるかと思いますが、読む側の立場で考えると、 「明示されている」「明示されていない」が混在しているのと 「必ず明示されている」のとでは、思考のシンプルさが違いますよね？

コーディング規約で対応しますか？

上記の制約は言語仕様として設けなくてもコーディング規約を
決めればすむ話じゃないの？

こういった意見もあるでしょう。 確かにすべてを自分のところでコーディングするならそれもよいでしょう。

最近では、開発スピードアップのために オープンソースプロジェクトを複数取り込んでの開発といった事も これからは増えていくことでしょう。

複数のプロジェクトすべてにおいて規約が一致する事は通常ありえません。

となると、あなたのソースもまたさらに別の規約を用いるか、 複数の規約が混在したコードになるでしょう。

こういった場合、可読性をいかに確保するようコーディングされていても その可読性を有効にするための前提条件が付け加えられます。

前提条件：頭の中の想定する規約をスイッチしてコードを読む。

この条件を満たさずにだらだら読む事は可能ですがきっと効率は悪いでしょう。

もちろん読む必要がないように設計すれば この辺の話は問題にはならないでしょうけれど。

自分の書いたコードを読む機会というのは ちょくちょく遭遇することだと思います。

結論

結論としてはこれらにはメリットがちゃんとあって 開発コミュニティの怠慢により放置されているのではないということです。

Pythonの思想に則り、「可読性」と「明示される」ということに 重点を置いて取捨選択され生き残った仕様なのです。

「明示される」事によるメリットは可読性にまた還元されうるので、 Pythonでは徹底して「コードの可読性」を 最重要視しているということなのかもしれませんね。

まとめ

Pythonとほかの言語との比較でほとんどの場合 デメリットとして引き合いに出されてしまう２つの特徴、 「インデント強制」と「self記述省略不可」。

同様にPythonユーザーはこれらの誤解にはもう飽き飽きしているようです。 「デメリットだ」という人に「メリットだ」と訴えても 簡単には分かって貰えないからです。 他言語ユーザーのホットさに比べて Pythonユーザーがひややかだと言う記述をどこかで見ましたが、 この辺りが関係しているのでしょうか？

多少なりともPythonに熱いファンがいることを表現したいと思い、 若干無理やりな事例を並べて下手な文章で書いてみました。 こういった事は感覚的に納得していても 具体的に説明するのは難しいですね。

実は私も、最初にためしにPythonを触ってみた時、

  • 「インデント強制だって！ひでー」
  • 「selfだらけじゃん」
  • 「へびいっぱいならんで気持ち悪い」

とか思ってしまっていったん離れています。 少し前に再会してみたらどっぷりはまってしまいましたが。

第一印象を鵜呑みにしてPythonという言語に 会うのが遅れた事は今思えばもったいなかったです。

誤解を少しでも解消できるようWeb上にこの文書を置いておきます。

次に学ぶ言語を選択する時には、 対象それぞれの誤解を解消してから検討して見てはどうでしょうか。

Oracle said:
“No one can see beyond a choice they don’t understand.”
「理解せずに選択した先は誰にもわからない」
投稿者 NoboNobo
カテゴリー: python
タグ: column