作为机械工程的博士后研究员，我第一次开始使用 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 的控制水平和灵活性非常出色——在 repo 中有一些漂亮的演示可供查看。
也就是说，初始学习曲线略微（但只是略微）陡峭，因为从一开始就掌握某些概念（例如 MVC 分离）是有帮助的。经验丰富的开发人员会立即看到其中的价值，但对于具有科学或工程背景的新用户来说，这可能是一个更大的障碍。不过，这只是一个小障碍，很容易清除。此外，虽然功能集已接近完成，但仍有一些漏洞。在填充它们方面取得了稳步进展，但从技术上讲，Enaml 仍处于测试阶段。
总的来说，如果你想决定学习哪个工具集，我的建议是学习 Enaml。这就是我们现在和将来会使用的。
[更新 - 2018 年 1 月]
由于此答案继续获得意见并引发对话，因此该意见的更新早就应该更新了，第一个答案可以追溯到 2012 年底。Enaml 主要是一个主要开发人员的工作。当他在 2013 年初离开 Enthought 时，他分叉了 enaml 存储库并开始在核酸/enaml存储库中开发它。我们（Enthought）决定不开发一个竞争分支，并引入了一个瘦接口库enthought/traits-enaml以提供与nucleic/enaml. 大约在同一时间，我们还引入了enthought/qt_binder以提供对 Traits/TraitsUI 框架中低级 Qt 小部件的轻松访问，该框架提供了与 Enaml 提供的大部分相同的布局灵活性。
现在 Traits/TraitsUI 是我们用于大多数应用程序 GUI 构建的堆栈。我们继续在 Python 2 和 3 中维护和开发 Enthought 工具套件（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 并直接从特征写入 DBAPI 层，可能为此目的定义一些自定义特征类型（例如，Property特征工厂，其fget并fset执行数据库查询）。
综上所述，承认我偏爱 Enthought 的技术，有一些工具可能更适合将简单的 CRUD UI 放在数据库之上。一种可能性是Dabo，但还有其他可能性，例如Camelot。