我正在寻找有关使用Traits / TraitsUI / enaml进行Python桌面开发的意见和经验。
文档和Enthought支持看起来很有前景，所以我想知道开发人员使用这个堆栈的真实第一手经验。
更新：
我主要关注的是迁移旧的几个桌面数据库应用程序：CRUD /查询/报告。然后，我特别感兴趣的是数据访问层：现在，我正在使用PosgtreSQL和peewee（一个简约的ORM）：
我首先开始使用Traits和TraitsUI构建GUI作为机械工程的博士后研究员。我之前构建GUI的经验是使用MATLAB的GUIDE，我发现TraitsUI非常简单易行，比较容易上手。 TraitsUI具有非常线性的进步与努力的进展，并且对于我用它做的有限数量的GUI构建，它已经绰绰有余了。
作为一名专业开发人员（完全披露：我在Enthought工作），我的观点有所改变。首先，区分Traits（打字，验证，通知和依赖系统）和TraitsUI（内置于Traits并基于Traits的GUI层）之间的区别非常重要。我一直使用Traits，它支持我写的很多代码。特别是对于它的依赖和通知实用程序，我认为它是非常宝贵的。
但是，开始进入应用程序构建的TraitsUI限制并不需要太长时间。正如我之前提到的，TraitsUI对于中小型应用程序已经足够了，但是创建更复杂的布局变得很困难，而且我们花了很多时间与TraitsUI进行斗争，以生成更大，更复杂和更灵活的应用程序界面。
这导致了Enaml或多或少的空白发展。 Enaml在其核心使用基于约束的布局系统，并与Traits集成。从一开始，它就解决了TraitsUI的布局缺陷。我们每个使用过两种系统的人都喜欢使用Enaml，我们认为它是GUI构建的首选工具。布局GUI的控制水平和灵活性非常显着 - 在回购中有一些漂亮的演示。
也就是说，初始学习曲线略微（但只是稍微）一些，因为从一开始就掌握某些概念，如MVC分离是有帮助的。经验丰富的开发人员会立即看到这一点，但对于具有科学或工程背景的新用户来说，这可能更具障碍。然而，这只是一个轻微的障碍，很容易被清除。此外，虽然功能集几乎完成，但仍有一些漏洞。在填补它们方面取得了稳步进展，但Enaml在技术上仍处于测试阶段。
总的来说，如果您要确定要学习哪个工具集，我的建议是学习Enaml。这就是我们现在将要使用的东西。
[更新 - 2018年1月]
由于这个答案继续获得观点并产生对话，因此这个观点的更新已经很久了，这是2012年末的第一个答案.Enaml主要是一个主要开发人员的工作。当他在2013年初离开Enthought时，他分叉了enaml存储库并开始在nucleic/enaml存储库中开发它。我们（Enthought）决定不开发竞争分支并引入了一个瘦的接口库enthought/traits-enaml来提供与nucleic/enaml变化的持续兼容性。大约在同一时间，我们还引入了enthought/qt_binder，以便在Traits / TraitsUI框架中轻松访问低级Qt小部件，这提供了与Enaml提供的大部分相同的布局灵活性。
现在Traits / TraitsUI是我们用于大多数应用程序GUI构建的堆栈。我们继续在Python 2和3中维护和开发Traits，TraitsUI和Enthought工具套件（Chaco，Kiva，Envisage等）中的其他库，它们继续满足我们的需求，特别是在enthought/envisage可插拔应用程序框架中。
我修改过的建议是，如果你想在Python中构建一个富客户端应用程序（不是一个Web应用程序），我会说要学习Traits和TraitsUI。
免责声明：我在Enthought担任开发人员和培训师。
要回答问题的次要部分，Traits中没有任何ORM或数据库支持，因此您必须自己滚动。这主要是因为Traits的开发是为了支持科学应用程序开发，而不是企业应用程序开发（但这就是为什么Traits确实支持NumPy支持）。
由于大多数ORM（例如SQLAlchemy，Django的ORM，我也看到Peewee）和Traits都使用声明式接口和元类来使定义对象结构变得非常容易，但是有一个不幸的尴尬。一起打得非常好。如果您想避免使用明确的桥接层，那么您需要对Traits和ORM有充分的了解。
如果我正在开发这种应用程序，我可能最终会避免使用ORM并直接从traits写入DBAPI层，可能为此目的定义了一些自定义特征类型（例如，Property特性工厂，其fget和fset执行数据库查询）。
所有这些都表示，并且承认我倾向于支持Enthought的技术，有一些工具可能更适合在数据库之上放置简单的CRUD UI。一种可能性是Dabo，但还有其他像Camelot。