パスワードを忘れた? アカウント作成
115016 story

Python 3.1リリース 16

ストーリー by hylom
しかしまだ3.xに移行していない人は多そう 部門より

ある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文に対する新たな文法
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by tuneo (2938) on 2009年07月01日 15時06分 (#1597377) ホームページ 日記

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

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

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

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

    • 自己レス。

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

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

      親コメント
      • いや、それはちょっと違うんじゃないかと(^^;)
        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ですので、こちらが正常に機能していないのではないかと思われます。

        親コメント
        • ・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環境変数を削除して実行したらパスしました。

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

          親コメント
  • by Anonymous Coward on 2009年07月01日 14時14分 (#1597329)
    Rubyの1.9.xもそうだけど、それまでから大きくかわったバージョンの系統は一般のユーザにはどれくらい使い物になるかという情報が乏しいとなかなか手を出せないので、そういうのもリリースノートかリリースに関するニュースには含めて欲しいところ。各種ライブラリの対応状況とか。
    • by Anonymous Coward on 2009年07月01日 21時50分 (#1597670)

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

      親コメント
    • by Anonymous Coward on 2009年07月01日 22時50分 (#1597705)
      とりあえず外部ライブラリに依存せず、標準ライブラリ内で完結するなら、今からでも3.xに移れます。
      標準ライブラリだけでも、かなりの事が出来るので、私は新規に作成する個人用ツールはほとんど3.0で書いています。

      2.x系から3.0に以降する上で、一番ひっかかるのは、importかな。
      ライブラリの構成が整備された副作用で、あそこにあったはずなのに何故かimport出来ないという事が結構あります。
      とはいえ、よく使うものは体が覚えてしまいますが。
      その他の点に関しては、意固地に2.2以前の書き方や旧スタイルクラスを使い続けるので無い限り、自然と移行できると思いますよ。
      もともと2.6以降の2.xは3.xへの助走として用意されているわけですし、2.8が出るあたりには、大方のライブラリは3.0に対応完了するんじゃないでしょうか。
      親コメント
    • by Anonymous Coward
      Djangoが3.xに対応するのは何時になるのかなぁ・・・
      今Python2.x系で色々作ってるんですが、このソースコードが3.x仕様で
      動かなくなるんじゃないかという不安が大きいです。
  • 雑感 (スコア:2, 参考になる)

    by T.Sawamoto (4142) on 2009年07月01日 19時53分 (#1597591)

    地味に嬉しいのが、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に近いので、個人的には残念ですが(^^;)

    • by leau (31991) on 2009年07月01日 21時01分 (#1597624) 日記

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

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

      親コメント
      • by ttm (8278) on 2009年07月02日 8時11分 (#1597835)

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

        親コメント
        • by Anonymous Coward
          ライブラリを蓄積するよりも言語としての完成度と一貫性を高めて欲しい。
    • by greentea (17971) on 2009年07月01日 23時11分 (#1597720) 日記

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

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

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

      --
      1を聞いて0を知れ!
      親コメント
typodupeerror

計算機科学者とは、壊れていないものを修理する人々のことである

読み込み中...