Support für Pythonprogramm gesucht

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Antworten
Papageno
User
Beiträge: 33
Registriert: Sonntag 21. Dezember 2014, 10:53

Hallo,

es ist hier zwar leider keine Jobbörse aber vielleicht findet sich wer. Für ein länger angelegtes Projekt benötige ich etwas Starthilfe. Dies soll sein:
- Struktureller Aufbau eines Python 3.6 Programmes
- Integration von Qt5.8 über pyQt und loadgui
- Einbindung der sqlite Datenbank

Details stelle ich Interessenten gerne bereit. Bezahlung nach Vereinbarung.

Gruß

Hans
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@Papageno:

Wie es denn um Deine Erfahrung mit Datenbank- und GUI-Programmierung, speziell PyQt, bestellt? Ohne ein paar Grundkenntnisse ist eine Starthilfe nicht sonderlich zielführend, dann ist eine Umsetzung nach Deinen Vorgaben eher das, was Du suchst.

An generellen Tipps bgzl. PyQt und Datenbank fällt mir ein:
- Ist eine native Desktop-Oberfläche wirklich besser geeignet als eine Netztechnologie? Häufig ist das nämlich nicht der Fall. Und mit dem Einsatz von Qt gewinnt man zwar natives Desktop-Look'n Feel, verliert aber die Flexibilität der Netztechnologien. (Man kann mit Qt auch beides haben, ist aber recht komplex vom Programmaufbau und fühlt sich auch eher unpythonisch an.)
- Nimm einen Python-ORM, vorzugsweise SQLAlchemy. Qt bringt zwar Datenbankunterstützung mit, das Interface ist aber ziemlich low level. Die paar Modelklassen in Qt mit dieser SQL-Anbindung kann man einfach mit Pythonsemantik nachbauen und muss sich nicht mehr mit QSqlQuery ins Knie schiessen.
- Falls das Programm prototypisch werden soll und z.B. eine spätere Portierung nach C++ geplant ist, dann sind obige Vorschläge eher hinderlich und Du solltest Qt-naher bleiben.
Papageno
User
Beiträge: 33
Registriert: Sonntag 21. Dezember 2014, 10:53

Hallo Jerch,

danke für deine Antwort. Die Problematik mit Webdesign contra Desktop habe ich auch schon beleuchtet. Ich sehe halt in Desktopprogrammierung effektiv mehr Optionen bei der Softwareerstellung. Das Programm soll später eben modular erweitert werden, Datenbankimport von msaccess, erstellen von Profilen für Messgeräte, Analyse mit sauberen Grafiken (matplotlib o.ä.) und lauter so Zeug von dem ich glaube dass es über Django oder anderes nicht so ohne weiteres zu erstellen ist. Zudem ist Netzwerkbetrieb zwar geplant, Webweit aber eher nicht. Dazu ist die gesamte Aufgabe zu komplex, meine ich. Aber da kann ich auch falsch liegen. Das möchte ich dann mal in Ruhe mit einem waschechten Programmierer diskutieren.

Zur Programmierseite: Ich habe mehrere Programme in VB entwickelt und bin seit 2 Jahren am Umstieg auf Python. Da ich zuwenig Zeit habe mich intensivst damit zu beschäftigen und für einen klassichen 3 Zeiler eher 3 Stunden als 3 Minuten brauche, möchte ich das Projekt mit fremder Hilfe anschubsen und hoffe dass ich vom praktischen dann schnell mehr hinbekomme.

Gruß

Hans
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

Papageno hat geschrieben:danke für deine Antwort. Die Problematik mit Webdesign contra Desktop habe ich auch schon beleuchtet. Ich sehe halt in Desktopprogrammierung effektiv mehr Optionen bei der Softwareerstellung. Das Programm soll später eben modular erweitert werden, Datenbankimport von msaccess, erstellen von Profilen für Messgeräte, Analyse mit sauberen Grafiken (matplotlib o.ä.) und lauter so Zeug von dem ich glaube dass es über Django oder anderes nicht so ohne weiteres zu erstellen ist. Zudem ist Netzwerkbetrieb zwar geplant, Webweit aber eher nicht. Dazu ist die gesamte Aufgabe zu komplex, meine ich. Aber da kann ich auch falsch liegen. Das möchte ich dann mal in Ruhe mit einem waschechten Programmierer diskutieren.
Für Django & Konsorten sprechen drei Dinge. Zum einen sind diese Rahmenwerke für zustandsloses CRUD konzipiert, was die Erstellung der Geschäftslogik sehr stark vereinfacht. Zum anderen bietet "browserbasiert" HTML/JS/CSS zur Frontendgestaltung, was schnell von der Hand geht im Vgl. zu allen nativen GUI-Bibliotheken. Und nicht zuletzt die bereits integrierte Netzwerkprotokollschicht, was eine Netzwerkumsetzung sehr leicht macht (egal ob lokal, Intra- oder Internet). Das sind 3 automagisch funktionierende Dinge, die, jedes für sich genommen, in einer eigenen Anwendung einiges an Konzeptions-, Implementations- und Integrationszeit verschlingen werden.

Hauptnachteil ist der Standardclient "Browser" mit der eingeschränkten Programmierbarkeit und Zugriffsmöglichkeiten auf das lokale System. Da hilft dann ein eigener browserbasierter Desktopclients weiter. Populär ist z.B. das chromium embedded framework, was in abgewandelter Form auch in Qt5 integriert ist (https://en.wikipedia.org/wiki/Chromium_ ... _Framework).

Und natürlich gibt es ein paar (wenige) Szenarien, wo ein "HTML-Stack" komplett ungeeignet ist - z.B. Echtzeitanforderungen auf allen Ebenen oder großes Datenaufkommen. Mitunter ist Python dann auch die falsche Wahl.
BlackJack

@jerch: Also das HTML/JS/CSS zur Frontendgestaltung im Vergleich zu GUI-Rahmenwerken leicht von der Hand geht, stimmt aber auch nur wenn man das schon kann. Ich persönlich kann jedenfalls Qt-GUIs leichter im Designer zusammenstellen als HTML/JS/CSS dafür zu schreiben, wo man auch mindestens ein Rahmenwerk für CSS für braucht und einige JS-Bibliotheken mit denen man auch erst einmal warm werden muss. Und da nimmt man dann entweder ein Rahmenwerk was an GUI-Rahmenwerke heran kommt, oder man darf sich verschiedene GUI-Elemente selber programmieren oder muss sich Plugins dafür zusammensuchen.

Nicht das ich falsch verstanden werde: Ich neige auch zu Webanwendungen wo das geht, schon alleine damit ich mich nicht mit Windows und Deployment auf alles mögliche auseinandersetzen muss. :-)
jerch
User
Beiträge: 1669
Registriert: Mittwoch 4. März 2009, 14:19

@BlackJack:
Jepp, so schön die Sache mit dem plattformübergreifend auch klingt, gerade mit C++ ist das Deployment von Qt-Anwendungen ziemlich nervig für unterschiedliche OS. Unter Python finde ich es nicht ganz so schlimm, da es ein Stück wegabstrahiert wird.

Bei HTML vs. nativer Oberfläche bin ich etwas voreingenommen, da ich die Möglichkeiten des Markups in Kombination mit CSS/JS doch sehr schätze. Wenn man das nicht braucht, reichen meist die QDesigner-Widgets. Will man allerdings eine ähnliche Flexibilität mit Qt, wird es entweder sehr hacky im Code oder man muss auf QML setzen. Letzteres ist de facto undokumentiert bzw. die vorhandene Doku nicht zu gebrauchen. Warum Digia da nicht nachbessert, obwohl QML seit längerem propagiert wird, ist mir ein Rätsel. Und nicht zuletzt hängt das Ganze auch von den zu präsentierenden Daten ab.
Antworten