質問

これは、Python 3がまもなくリリースされることを考慮して、ほとんどのpython開発者の心にあるテーマであると確信しています。正しい方向に進むための質問:

    • すでに開始しましたか、すぐに開始する予定ですか?または、最終バージョンが完全にリリースされるまで待つつもりですか?
役に立ちましたか?

解決

Twistedの一般的な計画は次のとおりです。私はもともとこれをブログするつもりでしたが、それからポイントを取得できるのになぜそれについてブログを書くのかと考えました。

  1. 誰かが気にするまで待ちます。

    今、誰もPython 3を持っていません。少なくとも1人の実際のユーザーが出て、「Python 3.0のサポートが必要です」と言って、十分な理由がある場合を除いて、多くの労力を費やすつもりはありません。 3.0がピカピカに見えるという事実から。

  2. 依存関係が移行するまで待ちます。

    Twistedのような大規模システムには、多くの依存関係があります。まず、次のものが含まれます。

    これらのプロジェクトのいくつかは、独自の依存関係の配列を持っているので、それらも同様に待つ必要があります。

  3. 誰かが十分に気になるまで待って助ける

    Twistedに取り組んでいる慈善団体は5人です。私は「慈善団体」と言います。それは私を数えているので、私は数ヶ月間コミットしていません。現在、 1000を超えるオープンチケットがあります。これらの一部を実際に修正して、 #8212;バグを修正し、機能を追加し、一般的にTwistedをより良い製品にします—実質的に新しいバージョンの言語に移植するために時間を費やす前に。

    これには、スポンサーが含まれます。 3.0のサポートに関心があり、コミュニティの前進を支援したいボランティアが流入します。

  4. Guidoのアドバイスに従ってください。

    これは、 互換性のないAPIを変更しないことを意味します 、および過渡的な開発に従いますGuidoが昨年投稿したガイドライン。それは、ユニットテストを開始し、Twistedコードベースで 2to3変換ツールを実行することから始まります。

  5. 2to3ツールに対するバグを報告し、パッチをファイルします

    実際に使用するところまで来たら、将来 2to3 を実行する際に多くの問題が発生すると予想しています。現在、Twistedで実行するには非常に長い時間がかかり(最後に確認しましたが、かなり前のことです)、Twistedリポジトリ内のファイルの一部を解析できないため、結果の出力はインポートされません。小規模なプロジェクトからかなりの量のサクセスストーリーがあり、ツールが実際に機能する前に、ツールに多くの打撃を与える必要があると思います。

    ただし、Python開発チームはバグレポートへの対応に非常に役立っており、これらの問題に対する早期の対応は勇気づけられているため、これらの問題はすべて時間内に修正されることを期待しています。

  6. マイ

他のヒント

Djangoプロジェクトは、ライブラリ six を使用して、機能するコードベースを維持します。 Python 2 Python 3(ブログ投稿)。

six は、インポートと機能をそれぞれの場所にインテリジェントにリダイレクトする互換性レイヤーを提供することでこれを行います(他の互換性のない変更を統合します)。

明らかな利点:

  • Python 2とPython 3の別々のブランチは不要
  • 2to3などの変換ツールはありません。

2.6の主なアイデアは、3.0への移行パスを提供することです。そのため、__ future__ import Xの を使用して、すべての機能をまとめて3.0に移行するまで、一度に1つの機能をゆっくりと移行できます。 3.0の機能の多くは2.6にも組み込まれるため、すべてを一度に移行するのではなく、言語のギャップを徐々に小さくすることができます。

職場では、最初に2.5から2.6にアップグレードする予定です。次に、3.0の機能を一度に1つのモジュールずつゆっくりと有効にします。ある時点で、システムのサブパート全体がおそらく3.xの準備が整います。

唯一の問題はライブラリです。ライブラリが移行されない場合、古いライブラリにとどまります。しかし、私はその部分の時間内に素晴らしい選択肢を手に入れると確信しています。

ライブラリ作成者として話す:

最終バージョンがリリースされるのを待っています。私の信念は、ほとんどのPythonコミュニティと同じように、2.xが数週間または数か月の間、支配的なバージョンであり続けるだろうということです。洗練された素晴らしい3.xリリースをリリースするのに十分な時間です。

2.xブランチと3.xブランチを別々に管理します。 2.xは2.4との後方互換性があるため、2.6 / 3.0の派手な構文や新機能の多くは使用できません。対照的に、3.xブランチはこれらの機能をすべて使用するため、ユーザーにとってより良いエクスペリエンスが得られます。テストスイートは2to3で動作するように変更され、両方のブランチで同じテストを維持します。

両方をサポート

現在取り組んでいるプロジェクトのためにBeautifulSoupライブラリを3倍に変換する試みをしたかったのですが、コードの2つの異なるブランチを維持するのがいかに苦痛になるかがわかります。

これを処理する現在のモデルは次のとおりです。

  1. 2xブランチに変更を加える
  2. 2to3を実行
  3. 最初に正しく変換されるように祈ります
  4. コードを実行
  5. 単体テストを実行して、すべてが機能することを確認します
  6. 出力を3xブランチにコピー

このモデルは機能しますが、私見ではダメです。変更/リリースごとに、これらの手順:: sigh ::を実行する必要があります。さらに、開発者がpy3kでのみサポートできる新機能で3xブランチを拡張することを思いとどまらせます。これは、本質的にすべてのコードを2xにターゲットしているためです。

解決策...プリプロセッサを使用する

Python用の#defineディレクティブと#ifdefディレクティブを使用して適切なCスタイルのプリプロセッサを見つけることができなかったため、1つ作成しました。

pypreprocessorと呼ばれ、PYPIで見つけることができます

本質的に、あなたがすることは:

  1. pypreprocessorをインポート
  2. スクリプトが実行されているPythonのバージョンを検出
  3. バージョンのプリプロセッサに「define」を設定します(例:「python2」または「python3」)
  4. コードがバージョン固有である場合、「#ifdef python2」および「#ifdef python3」ディレクティブを振りかける
  5. コードを実行

それだけです。これで、2xと3xの両方で動作します。プリプロセッサの実行によるパフォーマンスヒットの増加が心配な場合は、すべてのメタデータを取り除き、後処理されたソースをファイルに出力するモードもあります。

何よりも... 2to3変換を1回行うだけです。

これが実際の例です:

#!/usr/bin/env python
# py2and3.py

import sys
from pypreprocessor import pypreprocessor

#exclude
if sys.version[:3].split('.')[0] == '2':
    pypreprocessor.defines.append('python2')
if sys.version[:3].split('.')[0] == '3':
    pypreprocessor.defines.append('python3')

pypreprocessor.parse()
#endexclude
#ifdef python2
print('You are using Python 2x')
#ifdef python3
print('You are using python 3x')
#else
print('Python version not supported')
#endif

これらは端末での結果です:

 python py2and3.py
 >>>You are using Python 2x 
 python3 py2and3.py
 >>>You are using python 3x

ファイルに出力し、追加のメタデータなしでクリーンなバージョン固有のソースファイルを作成する場合は、pypreprocessor.parse()ステートメントの前のどこかに次の2行を追加します。

pypreprocessor.output = outputFileName.py
pypreprocessor.removeMeta = True

その後:

python py2and3.py

追加のメタデータなしでpython 2x固有のoutputFileName.pyというファイルを作成します。

python3 py2and3.py

追加のメタデータなしでpython 3x固有のoutputFileName.pyというファイルを作成します。

ドキュメントおよびその他の例については、 GoogleCodeのpypreprocessor をご覧ください。

これが役立つことを心から願っています。私はPythonでコードを書くのが大好きで、3xレルムへのサポートの進展を期待しています。私は言語が進歩しないことを嫌います。特に、3xバージョンでは多くの機能するWTFが解決され、他の言語から移行するユーザーにとって構文が少し見やすくなりました。

この時点でのドキュメントは完全ですが、広範囲ではありません。 Wikiについては、より詳細な情報を近日中に公開する予定です。

更新:

この問題を解決するためにpypreprocessorを特別に設計しましたが、コードが実行される前にレクサーがすべてのコードの構文チェックを行うため、動作しません。

Pythonが実際のCプリプロセッサディレクティブをサポートしている場合、開発者はpython2xとpython3kの両方のコードを同じファイルに同時に書き込むことができますが、Cプリプロセッサの評判が悪いため(言語を変更するためのマクロ置換の濫用)キーワード)正当なCプリプロセッササポートがPythonにすぐに追加されることはありません。

Zopeツールキットは、Python 3のサポートがゆっくりと進歩しています。これらのライブラリの多くが非常に複雑であるため、主に遅くなります。

ほとんどのライブラリでは、2to3を使用しています。一部のライブラリーは、単純であるか、C拡張機能のほとんどのコードを持っているため、これなしで済ますことができます。関連パッケージであるzc.buildoutは、Python 2および3をサポートするために2to3なしで同じコードを実行します。

TwistedやPyramidフレームワークなど、他の多くのライブラリとフレームワークがZTKに依存しているため、ZTKをPython 3に移植します。

より複雑な2.xコードの一部は、2.5または2.6のままです。 頻繁に使用するサードパーティライブラリの一部が3に更新されたら、すべての新しい開発のために3.0に移行します。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top