PyCon JP 2014の発表資料
宣伝が続いて恐縮だが、オライリージャパンよりPythonの解説書を上梓した。昔から、Python内部の仕組みも解説したPython解説書を書きたいと思っていて、ようやく実現した感じだ。
しかし、本書の執筆は、昔、構想を立てていたときに思っていたほどは楽しくはなかった。Python2ではなく、Python3.3以降を対象に書いてしまったからだ。Python3の型システムは綺麗に整理されてしまったし、メタクラスも扱いやすくなった。メモリアロケータは改善され、ガベージコレクションの注意点も大幅に減った。Unicodeの暗黙の変換も無くなった。私が書こうと思っていた知識の多くは、Python3では無用の長物と化した。
本書をPython2向けに書いていたら、今よりずっと多くのページ数を費やしただろう。Python3は、Python2よりも落とし穴が少なく、学習も容易なプログラミング言語だ。
そんな優れたPython3だが、「普及してないじゃないか」という声が上がっているようだ。以下、その件に関する感想を書いておく。
まあ、Python2に比べてば、普及してない。当然だ。Pythonは20年以上の歴史を持ち、熱心に開発され、幅広く利用されてきた。Pythonは、プログラミング史上、もっとも大きな成功を収めたプログラミング言語の一つだ。2008年末にリリースされた、若造プログラミング言語のPython3に太刀打ちできるはずがない。
一度作成されたプログラムが、大した理由もなしに別の言語や環境に対応することはありえない。時間が経てば、自然とPython2->3に移行されるというものではない。
現在、Python3がリリースされてから、5年ちょっと。Pythonが最初にリリースされてから5年経った頃というと、Python1.4とか1.5とかの頃だろうか。あの頃のPythonコミュニティも、まだまだ小さかった。今のPython3ユーザより、当時の全Pythonユーザの方が少ないのではないだろうか。comp.lang.pythonに流れるメールを全部読んでも大した量ではなかったし、開発者の数もわずかだった。リリースから10年以上たった2003年、私はPyCon USに遊びにいったが、その頃でも、参加者の数はたしか400人程度だった。
プログラミング言語の普及というのは、時間がかかるものだ。2000年代後半にも、いろいろなプログラミング言語が登場してきた。その中で、Python3以上のユーザを獲得した言語はどれだけあるだろうか?
同じ「Python」の名を冠してはいるが、Python3は、やはりPython2ではない。異なるプログラミング言語だ。Pythonはこれまで大きな成功を収め、巨大なエコシステムを築いてきた。沢山のモジュールが開発され、ほとんどのLinuxにはデフォルトでインストールされている。利用者に見えないところで、いろんなPythonアプリケーションが動いている。Windowsのシステムディレクトリには、いつの間にかPythonxx.dllがインストールされている。
Python3はPython2と互換性がないので、このエコシステムをそのまま利用することはできない。ほとんどのPython2モジュールは、Python3でも使えるようにするには修正が必要で、Python2と3両方で使えるようにするのは大変な作業だ。Python2専用か、Python3専用のどちらか決めてしまったほうが、はるかに簡単になる。
そういう意味で、Python2コミュニティと、Python3コミュニティは「分断」される。これから開発される、Python3用のモジュールやアプリケーションは、Python2コミュニティでは利用できないだろう。また、Python2だけを利用するユーザは、Python2専用のモジュールを開発するだろう。後知恵だが、Python開発者たちはPython2/3共用アプリの開発コストを低く見積もりすぎていた。Python3は、Python2という巨大なライバルを相手に、自分の陣地を獲得しなければならない。これには、まだ時間が必要だろう。
Python2は、未だに隆盛をきわめているが、その未来は明るくはない。御存知の通り、Python2の開発は終了しており、今後、Python2に機能追加などが行われることはない。結果として、Python開発チームは、とてもポピュラーなプログラミング言語を「殺し」、かわりにPython3という、新しいプログラミング言語を開発することを選んだ。
Python3なんかいらない、Unicodeなんか使わない、というユーザのいらだちは理解できる。Python2は十分現役で、そのまま使い続けるのに何の問題もないのに、お前のアプリ・モジュールは時代遅れになるから書き直せ、と言われてしまう。Pythonを単にツールに利用しているだけの人たちにとっては、迷惑なことだろう。
とはいえ、Python2は、非常に広く普及したので、本当に消えてなくなるまでには長い時間がかかるだろう。現在、bash などのシェルがこれだけ普及していても、移植性があるスクリプトを書くときには /bin/sh 用のスクリプトだけで書いたりするが、そんな感じで、/bin/python に Pyton2 がインストールされ続けるのかもしれない。そうなると、Python2の利用者が目に見えて減ることは無いのかもしれない。
今、Python2を使っているなら、焦る必要はない。いまあるPython2とライブラリで目的を果たせるなら、当面、Python2を使い続けるのは悪いことでもなんでもない。Python2の方が好きなら、全力でPython2をサポートするのもよいだろう。
しかし、分断されたPython2/3を統合するには、Python3のエコシステムを整備するしかない。Python3を強化し、Python2からの移行コストより、メリットが大きいことが明らかになるようにしなければならない。そのためには、ユーザがPython3を使い、改善に協力することが必要だ。
(ちなみに、個人的には、PEP 3003 Python Language Moratorium は間違いだったと思ってる。追いかけて欲しければ、全力で逃げるべきなのだ)
Python2か、Python3かで迷うなら、Python2を使うのも良いだろう。その昔は、Perlを使うか、Pythonを使うかで迷ったものだ。多少のリスクは覚悟した上で、Pythonを使っていた人たちがいて、その積み重ねがPythonの今日を作り上げた。同じ積み重ねが、Python3でもまた繰り返されると信じて、私は今日もPython3を起動している。
このたび、オライリージャパンよりPythonの解説書を出版させて頂くこととなった。表紙絵の動物は、犬ではなくアルプス・マーモットだ。
長年のあいだ、オライリージャパンの某氏にはPython本を書け書けとせっつかれていて、そのたびにうーんむにゃむにゃと誤魔化していたが、ついに書いたった。古い借金を返したようで、スッキリした。慶賀のいたりだ。
この本はPython3言語の解説書で、本人としては、プログラミング経験のある人なら読めるように、というつもりで書いている。Pythonの歴史から入って簡単なチュートリアルに進む、という正統派ストロングスタイルのプログラミング解説書だ。
しかし、本書を読むだけでは、Pythonプログラミングはマスターできない。Python3言語の文法とリストなど基礎的な組み込みオブジェクト、Pythonの実行モデルなどを中心に解説しており、Pythonの標準ライブラリについてはほとんど解説していないからだ。この決断のおかげで、本書は1000ページを超えるような電話帳まがいの本になることを回避できた。
しかし、その分、Pythonの式や構文についてはしっかリ解説できたと思っている。Pythonの名前空間やガベージコレクションなど、標準ドキュメントを読んでいるだけではなかなか理解しにくい、Pythonの実行モデルにかんする説明も記述できた。結構細かい点も深堀りしているので、それなりに経験を積んだPythonistaでも、本書から一つ二つぐらいは得るものがあるのではないかと思う。
Pythonにもいろいろ取り入れられていく過程で、説明が一箇所にまとまっておらず、ライブラリリファレンスと言語リファレンスと関連PEPに分散してしまっていたりする機能もある。そういった点も、できるだけこの本でまとめて解説するように心がけた。
私ももう20年近くPythonを使ってきたが、その中で、「この辺を押さえとくと、Pythonへの理解が深まるよ」というポイントを押さえて解説できたと思う。Pythonの活用に役立てていただきたいと、けっこうマジに願っている。
なお、この本は2014/9/18からの販売ではあるが、PyCon JP 会場では、9月13日のオライリーブースでフラゲ可能となっている。この販売は 9月13日 だけで、*14日には出展されていない* ので、ご注意を。
また、PyCon JP会場では、私は9月14日のジョブフェア会場 UNCOVER TRUTHブースに参加する。そこで本書の立ち読み&質問受付なんかもできると思うので、気軽にお声がけください。
Python 3.4の新規モジュール で、Python3.3以前用のパッケージが用意されているモジュールの一覧。
モジュール名 対象バージョン URL
enum 2.4 〜 3.3 https://pypi.python.org/pypi/enum34
asyncio 3.3 〜 <https://pypi.python.org/pypi/asyncio >
pathlib 2.7, 3.2 〜 <https://pypi.python.org/pypi/pathlib >
Python3で例外をキャッチすると、例外オブジェクトを代入した変数は削除される。
>>>a =100 >>> a 100 >>> try: ... 1/0 ... ... except Exception as a: ... pass ... >>> a Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'a' is not defined
Python Advent Calendar 2013 の六日目です。Python3.4 で導入された PEP 442 -- Safe object finalization の解説を簡単に。
Pythonでは、処理中に使われなくなったオブジェクトを検出し、自動的に開放するようになっている。他のオブジェクトから全く参照されておらず、Pythonインタープリタからアクセスできなくなってしまっているオブジェクトは、不要なオブジェクトとして削除される。
例えば、
>>> class Spam: ... pass ... >>> >>> obj = Spam() >>> obj = None
では、最初に作成した Spam
オブジェクトは、obj
という名前で参照できるが、次の行では obj = None
と別のオブジェクトを指すように変更されると、もうPythonインタープリタから参照できなくなる。このため、Pythonはこの
Spam
オブジェクトは不要となったと判断し、削除する。
他のオブジェクトからの参照があっても、孤立したグループ内でのみ参照されているなら、そのグループのオブジェクトは開放される。
>>> class Spam: ... pass ... >>> >>> obj1 = Spam() >>> obj2 = Spam() >>> obj3 = Spam() >>> obj1.obj2 = obj2 >>> obj2.obj3 = obj3 >>> obj3.obj1 = obj1 >>> obj1 = obj2 = obj3 = None
この例では、obj1
、 obj2
、obj3
オブジェクトは、それぞれお互いへの参照をメンバとして持っている。このように、複数のオブジェクトがループ状にお互いを参照することを、*循環参照*
と呼ぶ。
この循環参照は、最後の obj1 = obj2 = obj3 = None
で変数
obj1, obj2, obj3
が別のオブジェクトを参照するように変更されたので、どのオブジェクトもPythonインタープリタからはアクセスできなくなってしまった。Pythonは、このようにお互い同士では参照していても、外部からはアクセスできなくなってしまったオブジェクトも不要と判断し、開放する。
しかし、これまでのPythonでは、この循環参照の開放には制限があった。
>>> class Spam: ... def __del__(self): ... print('deleting...') ... global dont_kill_me ... dont_kill_me = self
このように、特殊メソッド __del__()
を持つオブジェクトが循環参照を構成する場合、開放の対象外となっていた。これは開放のときに
__del__()
メソッドを呼び出すと、その呼出の順番によってはすでに解放済みのオブジェクトを参照してしまったり、また自分自身を再び外部から参照可能な状態にしたりしてしまう可能性があったためだ。
上の例では、__del__()
でグローバル変数 dont_kill_me
にオブジェクトを保存しているので、Spam
クラスのインスタンスは削除されることはない。
Python 3.4以降では、PEP 442
でこの点が改善され、__del__()
を持つオブジェクトが循環参照に含まれていても、開放されるようになった。従来のメモリ解放処理に比べて、いくぶんか処理量が増加しているが、現在ではPythonにガベージコレクションが実装された西暦2000年頃に比べてコンピュータのハードウェア環境は大きく進歩しており、この程度はあまり問題とはならないだろう。
PEP 442での変更で、以下の点は気にしておいたほうが良いだろう。
循環参照の一部に、先ほどの
>>> class Spam: ... def __del__(self): ... print('deleting...') ... global dont_kill_me ... dont_kill_me = self
のようなオブジェクトが含まれている場合、オブジェクトは参照可能な状態に戻るので開放はされない。しかし、この場合開放はされなくても、循環参照を構成する、全てのオブジェクトの
__del__()
メソッドが呼び出される。つまり、Python3.4以降では、__del__()
が呼び出されたとしても、必ずオブジェクトが開放されるとは限らなくなった。
上の例で、すでに __del__()
が呼び出されてしまったオブジェクトが再び参照不能になったときでも、もう
__del__()
メソッドは呼び出されない。__del__()
が呼び出されるのは、ただ一度だけである。
(注: 例外として、 https://mail.python.org/pipermail/python-dev/2013-June/126834.html などのケースで複数回呼び出されることもありうるが、現実問題としてあまり考慮する必要はないだろう)
PEP 442 で、すべての循環参照が開放されるようになったわけではない。循環参照に含まれるオブジェクトがPythonのクラスから作成したインスタンスだけであれば開放されるが、C言語で実装された型のオブジェクトが含まれる場合、従来と同じように開放されないケースもある。
Python2で gc
モジュールが実装されて以来、__del__()
メソッドは実装するメリットよりもデメリットのほうが大きいと考えられ、できるだけ使わないようにするのが一般的だった。お陰で
with
ステートメントなどの機能が大きく進化することになったが、ここで再び
__del__()
のデメリットが少なくなったことで、__del__()
にいろいろな処理を詰め込みたいと思う人もいるかもしれない。
しかし、__del__()
のデメリットは、循環参照時に開放されないことだけではない。__del__()
が呼び出されるタイミングは予測できないし、全く呼び出されないかもしれない。先程の例のように、呼び出されたとしても本当に開放されたとは限らないし、マルチスレッドアプリケーションでは、どのスレッドで呼び出されるかも予測できない。__del__()
の活用には、いろいろと難しい点が残っている。
したがって、Pythonプログラミングのガイドラインとしては、「できるだけ
__del__()
に依存しない」というのは、依然として有効だと考える。くれぐれもC++のデストラクタと同じような使い方が出来ると思ってはならないのである。
Ubuntu 13.10 で普通にVMWare Fusion 6 の VMWare Tools をインストールしようとすると、
/vmhgfs-only/inode.c:1893:29: error: ‘struct dentry’ has no member named ‘d_count’
int dcount = dentry->d_count;
こんな感じでエラーになってしまう。
こちらの記事 を参考に、VMWare Tools側のソースにパッチをあてるとうまく動くようだ
$ cd vmware-tools-distrib/lib/modules/source $ tar xf vmhgfs.tar $ curl -O https://raw.github.com/rasa/vmware-tools-patches/master/patches/vmhgfs/vmhgfs-d_count-kernel-3.11-tools-9.6.0.patch $ patch -p0 < vmhgfs-d_count-kernel-3.11-tools-9.6.0.patch $ mv vmhgfs.tar vmhgfs.orig.tar $ tar cf vmhgfs.tar vmhgfs-only $ cd ../../.. $ sudo ./vmware-install.pl