Python 3.1リリース

あるAnonymous Coward 曰く、

6月27日付けでPython 3.1がリリースされている（SourceForge.JP Magazine）。

新機能や変更点はWhat’s New In Python 3.1をどうぞ。大きな改良点は下記のとおり。

• 順序付き辞書
• int型にさまざまな最適化が加えられた
• ユニットテストフレームワーク「unittest」の改良
• ioモジュールの高速化
• TkinterでのTileサポート
• import文のリファレンス実装となる、Pythonで実装されたimportlibモジュール
• ネストされたwith文に対する新たな文法

ソースからビルドしてみた

[tuneo (2938)]

Debian lenny(i386)のPCの上でソースからビルドしてみました。

……./configure→make allはつつがなく済んだのですが、しかる後にmake testしたらセルフテストでエラーがぼろぼろ出ましたorz。

いや、dbmとかsqliteとかtkとかgzipとかbz2のモジュールのテストがエラーになるのは分かるんですよ。
# 拡張モジュールの構築に必要なパッケージを入れてないから当たり前。

test_boolみたいな基本的なテストでエラーが出てしまって途方に暮れてます。

Re:ソースからビルドしてみた

[tuneo (2938)]

自己レス。

テストのログを見たところ、test_boolでこけるのは"\xa0".isspace()がFalseを返すのがお気に召さないからだそうです。

でも他の処理系ではどうなのよ？と疑問に思って、Debian lenny(i386)の上で動くPython2,5とWindowsの上で動くPython 2.6.1で上記の式を評価させてみたら……両方ともFalse。何だそりゃ？

Re:ソースからビルドしてみた

[T.Sawamoto (4142)]

いや、それはちょっと違うんじゃないかと(^^;)
Python 3.xのstrはUNICODEですから、 "\xa0".isspace() の結果は2.xとは異なるのが当然です。
（Ubuntu+Python 2.6でも、 u"\xa0".isspace() はTrueが返ってきました）

u+00a0 : NO-BREAK SPACE

なので、 "\xa0".isspace() の結果はTrueでなければいけません。
で、このstr.isspaceの実体は、Include/unicodeobject.hで定義されている通りCライブラリのiswspaceですので、こちらが正常に機能していないのではないかと思われます。

Re:ソースからビルドしてみた

[tuneo (2938)]

・test_bool
原因は「configureで--with-wctype-functionsを指定した」だった模様で、外して再度ビルドしたらtest_boolをパスするようになりました。Python3でUnicode文字列がデフォルトになったという重要事項を、頭に血が上りかけて一時失念していました。

・test_unicode
test_boolと同じ原因で失敗していたようで、これもconfigureしなおして再ビルドしたらパスするようになりました。

・test_urllib
「プロキシを経由せずに直接接続するホスト」が「localhost」だけなのがイクナイ(127.0.0.0/8が無い)ので失敗していたようですが、no_proxy環境変数を設定したらパスしました。
# いいのかそれで？

・test_urllib2_localnet
このテストはhttp_proxy環境変数がセットされていると失敗するみたいです。
http_proxy環境変数を削除して実行したらパスしました。

とりあえずこれで致命的なテスト失敗は全部つぶせたようです。

使い物になるの？

[Anonymous Coward]

Rubyの1.9.xもそうだけど、それまでから大きくかわったバージョンの系統は一般のユーザにはどれくらい使い物になるかという情報が乏しいとなかなか手を出せないので、そういうのもリリースノートかリリースに関するニュースには含めて欲しいところ。各種ライブラリの対応状況とか。

過去にも辿った道です

[Anonymous Coward]

Python 1.5→Python 2.xのときも移行に時間がかかってたっけな。あのときはライセンスも安定してなかった（GPL非互換になってしまって、それを直すのにGuidoが四苦八苦してた）から余計にね。Red Hat Linuxなどは標準のプログラミング言語として採用して独自ツールのほとんどをPythonで書いてたから、python2ってパッケージを別に用意してpythonパッケージ自体はしばらく1.5.xのままだった。非互換な変化は苦痛も与えてくれます。

Re:使い物になるの？

[Anonymous Coward]

とりあえず外部ライブラリに依存せず、標準ライブラリ内で完結するなら、今からでも3.xに移れます。
標準ライブラリだけでも、かなりの事が出来るので、私は新規に作成する個人用ツールはほとんど3.0で書いています。

2.x系から3.0に以降する上で、一番ひっかかるのは、importかな。
ライブラリの構成が整備された副作用で、あそこにあったはずなのに何故かimport出来ないという事が結構あります。
とはいえ、よく使うものは体が覚えてしまいますが。
その他の点に関しては、意固地に2.2以前の書き方や旧スタイルクラスを使い続けるので無い限り、自然と移行できると思いますよ。
もともと2.6以降の2.xは3.xへの助走として用意されているわけですし、2.8が出るあたりには、大方のライブラリは3.0に対応完了するんじゃないでしょうか。

Re:

[Anonymous Coward]

Djangoが3.xに対応するのは何時になるのかなぁ・・・
今Python2.x系で色々作ってるんですが、このソースコードが3.x仕様で
動かなくなるんじゃないかという不安が大きいです。

ワンライナー以上コントリビュータ未満ってとこかね

[Anonymous Coward]

元コメじゃないけど 該当言語で書かれた５００行以上のツールを作っていて日常使ってる 該当言語で書かれたフレームワークを使って、サイトの保守、管理をしている ってとこじゃね？ つまりユーザー

雑感

[T.Sawamoto (4142)]

地味に嬉しいのが、str.formatメソッドのフィールド番号が省略可能になった点ですね。
これはPython 3.0から追加された文字列書式化メソッドなのですが、従来は全てのフィールドに番号が必要でした。
（番号が振られるので、出力順序を変えられるという利点あり）

>>> print('foo = {0}, bar = {1}'.format(123, 456))
foo = 123, bar = 456

これが、Python 3.1からは省略可能になったようです。
（但し、出力順序は引数順固定、かつ番号指定形式との混在不可）

>>> print('foo = {}, bar = {}'.format(123, 456))
foo = 123, bar = 456

また、Python 3.1から旧タイプの文字列書式化演算子'%'が非推奨になります。
（PEP 3101 -- Advanced String Formatting [python.org]）
今すぐ消えてなくなるという訳ではないようですけど、今後Pythonのコードを新たに書くときにはご注意を。

# こっちの方がお手軽かつC言語のprintfに近いので、個人的には残念ですが(^^;)

Re:雑感

[leau (31991)]

また、Python 3.1から旧タイプの文字列書式化演算子'%'が非推奨になります。

非常に秀逸な演算子だと感じていたんですが、とても残念です。
Pythonがどんどん簡潔でなくなっていく…

Re:雑感

[ttm (8278)]

スクリプトを書き捨てる言語から、ライブラリを蓄積する言語に変わってきた感じがします。

Re:

[Anonymous Coward]

ライブラリを蓄積するよりも言語としての完成度と一貫性を高めて欲しい。

Re:雑感

[greentea (17971)]

built-in関数としてのformat()は、str()との違いを明確にさえできれば、結構嫌いじゃないかも、とは思いました。
表示に適した文字列を作るのが目的なら、フォーマット指定をサボってformatを呼び出したらどうなる？
strと同じ結果を返すのが自然な気がするけど、だとするとstrを呼び出す意味がなくなる。
表示に適してなくてもいいから印字可能な文字列ってのなら、既にrepr()があります。

str.formatは、番号を振ることができるといったメリットはあったとしても、そんなのは従来の%演算子に同等の機能を付け足せばいいだけで、そちらに変える必要がよく分からない。
どちらにせよ、単なる文字列の中に特定の文字列が登場したら、メソッドなり演算子なりで置換するという処理には変わりないわけだし、変えることのメリットが見えない。

特別な意味を持つ文字を変更してしまうと、ボーッとしてる人たちが直すの忘れてて、Python使ったCGIでの悪戯がたくさん起こる予感。

--
1を聞いて0を知れ!