Python デスクトップ開発でのTraits / TraitsUI / enamlの使用に関する意見や経験を探しています。
ドキュメンテーションと Enthought のサポートは有望そうに見えるので、このスタックを使用している開発者の直接の経験を知りたいと思いました。
アップデート：
私の主な関心は、古いいくつかのデスクトップ データベース アプリケーション (CRUD / クエリ / レポート) を移行することです。次に、特にデータ アクセス層に興味があります。現在、PosgtreSQL と peewee (最小限の ORM) を使用しています。
私は最初、機械工学のポスドク研究者として、TraitsとTraitsUIを使用してGUIを構築し始めました。GUIの構築に関する私の以前の経験は、MATLABのGUIDEでしたが、TraitsUIは非常に単純で、比較して簡単に始めることができました。TraitsUIは、努力に対して進歩が非常に直線的に進行しており、私がそれを使って行ったGUI構築の量が限られているため、それで十分でした。
プロの開発者として（完全な開示：私はEnthoughtで働いています）、私の見方は多少変わりました。まず、Traits（入力、検証、通知、および依存関係システム）とTraitsUI（Traitsに組み込まれベースになっているGUIレイヤー）を区別することが重要です。私は常にTraitsを使用しており、それは私が作成するコードの多くを支えています。特に依存関係と通知ユーティリティに関しては、非常に貴重だと思います。
ただし、アプリケーション構築のためのTraitsUIの制限にぶつかり始めるのにそれほど時間はかかりません。前述したように、TraitsUIは中小規模のアプリケーションには十分ですが、より複雑なレイアウトを作成することは困難であり、TraitsUIと格闘して、より大きく、より複雑で柔軟なアプリケーションインターフェイスを作成することに多くの時間を費やしていました。
それは多かれ少なかれEnamlの白紙の状態の開発につながりました。Enamlは、そのコアで制約ベースのレイアウトシステムを使用し、Traitsと統合します。最初から、TraitsUIのレイアウトの弱点に対処します。両方のシステムを使用したことのある私たち全員がEnamlを好み、これは今後のGUI構築に最適なツールであると考えています。GUIをレイアウトするための制御と柔軟性のレベルは驚くべきものです-リポジトリでチェックアウトするための気の利いたデモがいくつかあります。
とはいえ、MVCの分離などの特定の概念を最初から把握しておくと役立つため、初期学習曲線はわずかに（ただしわずかに）急になります。経験豊富な開発者は、この価値をすぐに理解できますが、科学または工学のバックグラウンドを持つ新規ユーザーにとっては、よりハードルになる可能性があります。しかし、それはほんのわずかなハードルであり、簡単にクリアできます。また、機能セットはほぼ完成していますが、まだいくつかの穴があります。それらの記入は着実に進んでいますが、Enamlは技術的にはまだベータ版です。
全体として、学習するツールセットを決定しようとしている場合は、Enamlを学習することをお勧めします。それが私たちの現状であり、今後も使用していきます。
[更新-2018年1月]
この回答は引き続き意見を集め、会話を生み出しているため、この意見の更新は長い間行われています。最初の回答は2012年後半にさかのぼります。Enamlは主に1人の主要な開発者の仕事です。2013年の初めにEnthoughtを去ったとき、彼はenamlリポジトリをフォークし、nuclear /enamlリポジトリで開発を開始しました。私たち（Enthought）は、競合するフォークを開発しないことを決定し、の変更との継続的な互換性を提供するために、シンインターフェイスライブラリenthought/traits-enamlnucleic/enamlを導入しました。同じ頃、enthought / qt_binderを導入して、Traits / TraitsUIフレームワークの低レベルQtウィジェットに簡単にアクセスできるようにしました。これにより、Enamlが提供するのと同じ種類のレイアウトの柔軟性が提供されます。
現在、Traits / TraitsUIは、ほとんどのアプリケーションGUI構築に使用するスタックです。私たちは、Python2および3のEnthoughtTool Suite（Chaco、Kiva、Envisageなど）でTraits、TraitsUI、およびその他のライブラリを維持および開発し続けており、特にenthought/envisageプラガブルで私たちのニーズを満たし続けています-アプリケーションフレームワーク。
私が修正した推奨事項は、Pythonでリッチクライアントアプリケーション（つまり、Webアプリではない）を構築する場合は、TraitsとTraitsUIを学ぶことです。
免責事項: 私は Enthought で開発者およびトレーナーとして働いています。
質問の二次的な部分に答えるには、Traits に組み込まれている ORM またはデータベースのサポートがないため、独自のものを作成する必要があります。これは主に、Traits がエンタープライズ アプリの開発ではなく、科学的なアプリケーション開発をサポートするために開発されたためです (ただし、Traitsに NumPy のサポートが組み込まれているのはそのためです) 。
ほとんどの ORM (SQLAlchemy、Django の ORM、Peewee も見ます) と Traits の両方が宣言型のインターフェイスとメタクラスを使用してオブジェクト構造を非常に簡単に定義できるという事実によって引き起こされる残念な厄介さがありますが、そうではないという欠点があります。一緒にとても仲良く遊んでいます。明示的なブリッジ レイヤーを回避したい場合は、Traits と ORM の両方をしっかりと理解する必要があります。
もし私がこの種のアプリを開発していたら、おそらく ORM の使用を避け、trait から DBAPI レイヤーに直接書き込み、この目的のためにいくつかのカスタム trait タイプを定義することになるでしょう (例えば、trait factoryPropertyとfgetexecutefsetデータベース クエリ）。
とはいえ、Enthought のテクノロジを好む私の偏見を認めれば、単純な CRUD UI をデータベースの上に配置するのにより適したツールがいくつかあります。1 つの可能性はDaboですが、他にもCamelotなどがあります。