Meinungen über Enthought Traits / TraitsUI für Python-Desktop-Entwicklung

Ich begann Traits und TraitsUI zum Aufbau von GUI als Postdoc-Forscher im Maschinenbau zu verwenden. Meine vorherigen Erfahrungen mit dem Erstellen von GUI's waren mit MATLABs GUIDE, und ich fand, dass TraitsUI sehr einfach und leicht zu vergleichen ist. TraitsUI hat eine sehr lineare Progression von Fortschritt versus Anstrengung, und für die begrenzte Menge an GUI-Erstellung, die ich damit gemacht habe, war es mehr als ausreichend.

Als professioneller Entwickler (vollständige Offenlegung: Ich arbeite bei Enthought) hat sich meine Perspektive etwas verschoben. Zunächst ist es wichtig, zwischen Traits (dem Typisierungs-, Validierungs-, Benachrichtigungs- und Abhängigkeitssystem) und TraitsUI (dem GUI-Layer, der in Traits aufgebaut ist und darauf basiert) zu unterscheiden. Ich benutze Traits die ganze Zeit, und es enthält eine Menge Code, den ich schreibe. Besonders für seine Abhängigkeits- und Benachrichtigungsdienstprogramme halte ich es für unschätzbar.

Es dauert jedoch nicht zu lange, um mit den Einschränkungen von TraitsUI für den Anwendungsaufbau zu beginnen. Wie bereits erwähnt, ist TraitsUI für kleine bis mittelgroße Anwendungen ausreichend, aber es wird schwierig, komplexere Layouts zu erstellen, und wir verbrachten viel Zeit mit TraitsUI, um größere, komplexere und komplexere Anwendungsschnittstellen zu erstellen.

Das führte zur mehr oder weniger leeren Entwicklung von Enaml. Enaml verwendet ein Constraint-basiertes Layout-System und integriert es in Traits. Es adressiert von Anfang an die Layout-Schwächen von TraitsUI. Jeder von uns, der beide Systeme verwendet hat, bevorzugt Enaml und wir betrachten es als das Werkzeug der Wahl für die Weiterentwicklung von GUI. Das Maß an Kontrolle und Flexibilität beim Layout von GUI's ist bemerkenswert - es gibt einige nette Demos, die man im Repo ausprobieren kann.

Das heißt, es gibt eine leichte (aber nur wenig) steilere anfängliche Lernkurve, da es hilfreich ist, bestimmte Konzepte wie MVC-Trennung von Anfang an zu verstehen. Ein erfahrener Entwickler würde den Wert sofort sehen, aber es könnte für einen neuen Benutzer mit einem wissenschaftlichen oder technischen Hintergrund eher eine Hürde darstellen. Es ist nur eine kleine Hürde und leicht zu klären. Während das Feature-Set fast fertig ist, gibt es immer noch ein paar Löcher. Es gibt stetige Fortschritte beim Ausfüllen, aber Enaml ist technisch noch in der Beta.

Wenn Sie versuchen zu entscheiden, welches Toolset Sie lernen sollen, ist es meine Empfehlung, Enaml zu lernen. Es ist, was wir sind und zukünftig verwenden werden.

[UPDATE - Jan 2018]

Da diese Antwort weiterhin Ansichten vermittelt und zu Gesprächen führt, ist eine Aktualisierung dieser Meinung längst überfällig, die erste Antwort stammt aus Ende 2012. Enaml war größtenteils die Arbeit eines Hauptentwicklers. Als er Anfang 2013 Enthought verließ, gab er das Enaml-Repository frei und begann, es im Nu- cle / Enaml -Repository zu entwickeln. Wir (Enthought) haben uns entschieden, keine Konkurrenzgabel zu entwickeln und haben eine dünne Interface-Bibliothek eingeführt, die fortwährende Kompatibilität bietet mit Änderungen in nucleic/enaml . Etwa zur gleichen Zeit haben wir auch enthought / qt_binder eingeführt, um einfachen Zugriff auf Low-Level-Qt-Widgets im Traits / TraitsUI-Framework zu ermöglichen bot viel von der gleichen Layout-Flexibilität wie Enaml.

Traits / TraitsUI ist der Stack, den wir für die meisten GUI-Anwendungen verwenden. Wir pflegen und entwickeln weiterhin Traits, TraitsUI und die anderen Bibliotheken in der Enthought Tool Suite (Chaco, Kiva, Envisage, etc.) in Python 2 und 3, und sie erfüllen weiterhin unsere Bedürfnisse, insbesondere in der http://thought/envisage Plug-in-Application-Framework.

Meine geänderte Empfehlung lautet: Wenn Sie eine Rich-Client-Anwendung (in Python keine Webanwendung) erstellen möchten, würde ich Traits und TraitsUI lernen.

Disclaimer: Ich arbeite als Entwickler und Trainer bei Enthought.

Um den sekundären Teil der Frage zu beantworten, gibt es keinen ORM- oder Datenbank-Support, der in Traits eingebunden ist. Sie müssen also Ihre eigenen Rollen erstellen. Dies ist hauptsächlich darauf zurückzuführen, dass Traits entwickelt wurde, um die Entwicklung wissenschaftlicher Anwendungen zu unterstützen, und nicht um die Entwicklung von Unternehmens-Apps (aber deshalb haben Traits NumPy-Unterstützung).

Es gibt eine unglückliche Ungeschicklichkeit, die dadurch verursacht wird, dass die meisten ORMs (wie SQLAlchemy, Djangos ORM und ich auch Peewee) und Traits deklarative Interfaces und Metaklassen verwenden, um das Definieren von Objektstrukturen sehr einfach zu machen, aber am Nachteil, nicht sehr gut zusammen zu spielen. Wenn Sie eine explizite Überbrückungsschicht vermeiden möchten, müssen Sie sowohl die Eigenschaften als auch das ORM gut verstehen.

Wenn ich diese Art von App entwickeln würde, würde ich wahrscheinlich die Verwendung des ORM vermeiden und direkt aus Merkmalen in den DBAPI-Layer schreiben und möglicherweise einige benutzerdefinierte Merkmalstypen für diesen Zweck definieren (zB Property Merkmal) Fabriken, deren fget und fset Datenbankabfragen ausführen.)

All das gesagt, und zu meiner Voreingenommenheit zugunsten der Technologien von Enthought einzugestehen, gibt es einige Werkzeuge, die eher dazu geeignet sind, einfache CRUD-Benutzeroberflächen auf einer Datenbank zu platzieren. Eine Möglichkeit ist Dabo , aber es gibt andere da draußen wie Camelot .