PEP 3003 Python Language Moratorium

PEP 3003 Python Language Moratorium が accept されたようです。この PEP は、当分の間、 Python 3.x の文法を変えませんよ宣言するものです。この変更の一時停止期間をモラトリアムと呼んでいます。

モラトリアムの意図は、Jython や IronPython などが、Python 3.x を実装しやすくするためです。しばらくしたら、IronPython の 3.x 系が出てくるかも。以下、おおざっぱなまとめ。

• Python 3.1 リリース以降、2年間は Python の文法、セマンティクス、ビルトイン関連の変更を行わない。



• Python 3.2 リリースはモラトリアム期間内なので、言語への変更はない。



• Python 3.3 リリースはモラトリアム期間外なので、言語への変更が起こりうる。

変更しないもの

• 新しいビルトイン



• 文法: 文法ファイルは不変とし、あいまいな理由で修正をしてはならない。



• セマンティクス: 特定の例外（下記を参照）をのぞいて、言語としての動作は現状を維持する。



• __future__ でインポートできるもの: 言語の文法やセマンティクスに影響するので。

場合によっては変更するもの

• ビルトインの新規メソッド



• 不適切なセマンティクスの修正: 言語のセマンティクスがあいまいだったり、元々の設計に反して、不適切に実装されている場合は、セマンティクスの変更してもよい。



• セマンティクスの実装が、著しく困難な場合: CPython 以外で、Python 3.x を実装することが著しく困難な場合には、他の VM にがPython 3.xの採用を容易できるようにしてよい。

変更してもよいもの

• C API



• 標準ライブラリ



• 3.x から 2.x へのバックポート



• import のセマンティクス

BP Study #27 で Python 3 について話しました

勉強会 BP Study #27 で、Python 3 について話しました。内容は、Python Code Reading 03 の内容とほとんど同じで、3.1 のことを、ちょっとだけ追加した程度です。Code Reading と BP Study は微妙に参加者が違うので、これでいこう、と。

bpstudy27 Python 3 資料

Python 3 がリリースされてから 1年ほどたちますが、まだまだ Python 2 から 3 への移行は進んでいないようです。Python 開発陣も、そんな性急な移行を期待しているわけではないようですし。

ただ個人的な、そしておよそ合理的ではない期待として、Python 3 への移行が進むとよいな、と思っています。理由のひとつは Python 3 の言語としての一貫性が、好きであるということです。next(x) よりも x.next() のほうがいいとか、些末な不満はありつつも全体として Python 3 が好きです。

Django や GAE が、まだ Python 2.x ベースなので、いきなり業務へ、というわけにはいかないにしても、個人ベースではいくらでもできることはあると思います。というわけで、文書書いたり、既存ライブラリの移植とか、そういうことをやってみようかな、と小さく囁いてみる。

assigned vs own ではなく

今朝がた、

プロジェクトを assign されたのではなく、own していると考えると、何か変わったりするのだろうか。こういう体育会系的な気持ちの持ちようみたいなのは嫌いだけれど、アクションに影響が出るなら、気持ちの持ち方を変えてみたい。

などと、つぶやいたのだけれど、これがあまりにひどい言い方なので、ちと書き直し。というか、まとめ直し。

少し前まで、大きめの組織に所属していました。やりたくてもさせてもらえないことがあった一方で、他の人にお願いできることもたくさんあったと思います。

今は小回りのきく組織に所属しています。そうすると、他の人にお願いできることが減った分、自分が決めていいこと、やっていいこと、やめていいこと、ほっといていいことなどの選択肢が大幅に増えました。これは予想の範囲。

予想していなかったこと（でも予想は可能だったはず）は、自由度が大きくなると、制御しようとする系が複雑になるということ。そんなことは、大昔に学校で習ったことであるのに。締切ひとつとってもそう。数ヶ月後にまとまった成果を上げないといけないとしましょう。そのためにいくつかの細かいタスクが存在します。各タスクの締切をいつにするか。来週でもいいし、再来週くらいでもよい。でも幅をもたせていていては締切にならないし。で、締切の設定の仕方によって、成果が変わる可能性があって、じゃあ成果側を定義しようとすると締切に影響があって、みたいな非線形な関係になっていたりする。

そして、こういうときの工学的な解決方法も学校で教わっている。境界条件を満たしておけば、とりあえず適当に決める。そして、適当に決めた数字の妥当性を評価し、その結果によって、数字を上げ下げする、というのを繰り返すのが数値計算のやりかた。

で、assign と own に話をもどしましょう。一般に assign された仕事は自由度が低く、own している仕事は自由度が大きい傾向があるような気がします。一般にそういう相関がありそうである、という程度の意味で。実際に私が直面していたのは、自由度の大きさのせいで、問題解決空間の大きさに圧倒されていただけだったのだと、今頃気づきました。