Das deutsche Python-Forum

Hallo zusammen,

mein anfänglicher Enthusiasmus für Python wird momentan immer wieder stark gebremst, seit dem ich versuche, etwas mit OpenGl zu machen. Dieses mal ist es pyglet, welches ich mit pip (python34) fehlerfrei installiert habe. Wenn ich es benutzen will, bekomme ich folgenden Fehler beim Import: In Zeile 249 steht eindeutig Python2-Code: Wieso kann das sein, wenn ich es mit pip(3) installiert habe ?

Grüße
m-o

mephisto-online hat geschrieben:Wieso kann das sein, wenn ich es mit pip(3) installiert habe ?

Wenn ich mich richtig erinnere musste man das mit der passenden Setup-Routine installieren, da damit dann hinterher noch 2to3 über den Code läuft. Such mal in der Dokumentation für das Modul.

Wenn ich mit pip(3) installiere, setze ich voraus, dass das auch für Python3 ok ist. Zum Basteln habe ich keine Lust ! Ich möchte gerne meinen Hirnschmalz in mein Programm investieren und nicht in die gebastelte Umgebung von Python3.

Sagt mal, kann das sein, das der Mensch der Python macht, zu Python3 mit seinen diversen Erweiterungen von der Python-Community gezwungen wurde und es gar nicht mag und somit auch nicht supportet ? Mit Python 2 geht immer alles !

Sowas hatte ich mal in Golem gelesen. Mr. Python sagte (Namen von Leuten kann ich mir schlecht merken...), dass Python 2.7 wirklich die letzte 2er Release wäre, es hörte sich aber nicht sehr überzeugend an.

Aber ich möchte gerne was auf die Beine stellen und mich nicht mit irgendwelchen Animositäten von genialen Programmierern herumschlagen.

Heute Nacht hatte ich schon wieder so ein DejaVu mit Python: Ein sehr gutes Frontend für OpenGL scheint mir Processing2 zu sein - als ich die Python-Bindings installieren wollte, war wieder mal "geht nicht" angesagt. Mit Java keine Probleme !

Für Datengewusel und die Qt-Oberfläche ist Python wirklich ausgezeichnent ! Aber für Grafik kann man es echt vergessen. - zumindestens unter Linux. Was Windows angeht, kann ich mir kein Urteil erlauben. (so ein schlechtes Betriebssystem leiste ich mir im Moment nicht, weil ich nicht die Hardware dafür habe - keine Proc-Virtualisierung - Win7 und 8 - Lizenzen liegen vor) Auf Mac OSX scheint das besser zu funktionieren: Einer meiner Söhne hat die Abhängigkeiten für mein Projekt in 2 Stunden hinbekommen, unter Linux habe ich Tage gebraucht !

Ja, C# wäre toll, aber Mr. Mono (und GNOME) hat sich ja auch eher dem Geld zugezogen gefühlt und sich von MS kaufen lassen (Xamarin). Und das kostet Geld. Mono selbst (für alle Plattformen) wird leider nicht wirklich weiterentwickelt. Entwickler raten von der Benutzung jedenfalls ab !

Da scheint doch wohl Java das Einzige zu sein, was man im Moment wirklich systemübergreifend (und frei !) denken kann.

Grüße
m-o

P.S.: Es tut mir wirklich leid, mein liebgewonnenes Python (es ist wirklich eine schöne und gut gemachte Sprache !) wegen des Versions-Debakels verlassen zu müssen. Aber Java (mittlerweile problemlos auch in der Version scheint da immer noch auf wesentlich sichereren Füßen zu stehen !

mephisto-online hat geschrieben:Sagt mal, kann das sein, das der Mensch der Python macht, zu Python3 mit seinen diversen Erweiterungen von der Python-Community gezwungen wurde und es gar nicht mag und somit auch nicht supportet ? Mit Python 2 geht immer alles !

Der Übergang von Python 2 auf Python 3 ist bei manchen Projekten etwas schwerfälliger.

Du scheinst hier allerdings davon auszugehen, dass alle Python-Erweiterungen kontrolliert von einer zentralen Instanz gesteuert und koordiniert werden. Das ist allerdings nicht der Fall. Was du auf PyPi oder sonstwo findest sind vom Sprachkern unabhängige eigenständige Projekte. Wenn diese nicht so weit sind, dass sie mehrere Python-Versionen unterstützen, dann ist das bedauerlich, hat aber nichts mit "dem Menschen der Python macht" zu tun.

Wenn also die Bibliotheken die du benötigst nur auf Python 2.7 vorhanden sein, dann verwende halt Python 2.7. Wenn du dich mit Java wohler fühlst und die gewünschten Bibliotheken von Java aus problemlos einzubinden sind dann verwende Java.

@me
Das finde ich nett, dass man sich mit Dir mal ohne Anfeindungen hier auch über die "Schmerzen" mit Python unterhalten kann.

/me hat geschrieben:Der Übergang von Python 2 auf Python 3 ist bei manchen Projekten etwas schwerfälliger.

Das Problem gibt es ja bei jeder Migration. Mein Projekt hatte ich Python-Greenhorn aber direkt mit Py3 gemacht. Das Ganze jetzt nach 2.7 downzugraden, ist bei dem Umfang des Programms glaube ich ziemlich aufwendig.

/me hat geschrieben:Du scheinst hier allerdings davon auszugehen, dass alle Python-Erweiterungen kontrolliert von einer zentralen Instanz gesteuert und koordiniert werden.

Nein, das ist ja bei keiner Sprache so. Aber Bibliotheken installieren geht eigentlich immer auf dieselbe Weise. Bei Python ist genau dieser Punkt extrem undurchsichtig !

/me hat geschrieben:Wenn diese nicht so weit sind, dass sie mehrere Python-Versionen unterstützen, dann ist das bedauerlich, hat aber nichts mit "dem Menschen der Python macht" zu tun.

Natürlich hat der "Mensch von Python" nichts damit zu tun. Aber er hat zumindestens die Python-Community insofern verunsichert, das er selbst von Python3 nicht sonderlich überzeugt ist. Er musste Spachelemente bei 3 hinzufügen, die er für nicht sinnvoll erachtet und die nicht in sein Konzept "Nur eine Möglichkeit für ein Problem" passt. Und mit der Erscheinung von 2.7 hat er diese Verunsicherung dann schon ein wenig manifestiert (ich habe jetzt keine Lust, nochmal danach zu suchen, weder wie er heisst, noch wo er das gesagt hat. Ich nehme mal an, dass Golem berichtet hat, weil ich es regelmäßig lese).

/me hat geschrieben:Wenn also die Bibliotheken die du benötigst nur auf Python 2.7 vorhanden sein, dann verwende halt Python 2.7.

Naja, wenn Pakete für Python3 nicht vorhanden sind (wie offensichtlich pyglet), sollten sie ja eigentlich auch nicht mit pip(3) installierbar sein, oder ? Wenn mir das Debakel mit Python3 bewusst gewesen wäre, hätte ich die viele Arbeit wohl erst mal in Py2 gemacht.

/me hat geschrieben:Wenn du dich mit Java wohler fühlst ...dann verwende Java.

Nein, von der Sprache her ist Python um einige Wellenlängen besser als Java. Aber ich habe keine Lust, mich permanent mit irgendwelchen "Installationsproblemen" herumschlagen zu müssen.

Nun gut, jetzt habe ich halt ein PySide-Programm für die Datenhaltung und Steuerung und Java-Programme für die Grafik.

@mephisto-online: Beim Pyglet-Eintrag im Package-Index steht keine Python-Versionsangabe. Was soll ``pip`` dann machen? Grundsätzlich die Intstallation verweigern? Oder das nur unter Python 3 machen? Letztlich fällt es IMHO in die Verantwortung der Leute die das Package erstellt und die Information in den Index gestellt haben. Also konkret in diesem Fall die Pyglet-Autoren.

Ich sehe nicht wo Guido van Rossum (der Mensch von Python) nicht überzeugt von Python 3 ist. Er hört halt, obwohl er letztendlich der ”Alleinherrscher” ist, auch auf die Benutzer. Und wenn die eine bestimmte Funktion oder ein Sprachfeature wichtig finden, dann entscheided er sich auch mal gegen das was er machen würde, wenn er der einzige Benutzer der Sprache wäre. Ich denke mal es geht hier um so Sachen wie ``lambda`` oder `reduce()`, was er gerne rausgeworfen hätte.

@BlackJack
Genau, so heist dieser geniale "Mensch": Guido van Rossum ! Aber an ihm liegen solche Probleme wie mit pyglet sicherlich nicht.

Vielleicht ist pyglet (oder Python überhaupt ?) aber auch nicht das richtige Mittel der Wahl, wenn man moderes OpenGL programmieren möchte. Mit Python3 habe ich ja schon bei den PyOpengl-Paketen grosse Probleme gehabt. Man findet im Internet auch wenig Aktuelles über Grafik-Programmierung in Python.

Jetzt suche ich halt noch nach einer etwas kompfortableren Grafik-Bibliothek, weil die Programmierung von OpenGL selbst doch sehr aufwendig ist (und ich das sowieso direkt in C machen würde). Vielleicht bekomme ich ja doch noch das "Processing2" irgendwie anders unter Py3 ans Laufen. Mit der von Processing selbst vorgesehenen Möglichkeit der Installation der Python-Bindings geht es jedenfalls bei mir nicht.

Vielleicht liegt das ja auch alles nur an der Tatsache, dass ich mit einem für solche Sachen "unbetreutem" Linux arbeite.

mephisto-online hat geschrieben:Natürlich hat der "Mensch von Python" nichts damit zu tun. Aber er hat zumindestens die Python-Community insofern verunsichert, das er selbst von Python3 nicht sonderlich überzeugt ist. Er musste Spachelemente bei 3 hinzufügen, die er für nicht sinnvoll erachtet und die nicht in sein Konzept "Nur eine Möglichkeit für ein Problem" passt.

Das habe ich in Beiträgen von Guido (van Rossum) und in Unterhaltungen mit ihm allerdings grundsätzlich anders wahrgenommen. Der BDFL steht absolut deutlich hinter Python 3.

Um das Problem mal von der anderen Seite anzugehen: Was möchtest du denn visualisieren? Die Anwendungsfälle in denen ich mittels Python direkt auf OpenGL-Ebene arbeiten wollen würde sind eher wenige. Normalerweise würde ich auf abstraktere Bibliotheken wie Matplotlib, Mayavi, Pygame, oder Panda3D zurückgreifen. Wenn du unbedingt mit den gl*-Funktionen direkt arbeiten willst/musst, dann kannst du das auch gleich in C oder C++ machen und Python sparen. Der Code ist dann quasi identisch, warum solltest du dir dann noch den Umweg über Python antun?

Ansonsten gilt aber auch für C/C++: Die direkte benutzung von gl*-Funktionen ist sehr selten, in den meisten Fällen ist eine Abstraktionsschicht vorhanden. Durchgesetzt hat sich mittlerweile OSG, da bekommt man von OpenGL nicht mehr viel mit. Außer man möchte das, aus Performancegründen, Einfachheit oder weil man eigenen Shadercode braucht, unbedingt tun.

EyDu hat geschrieben:Was möchtest du denn visualisieren?

Darstellung von texturierten (und später sich vielleicht bewegenden) VBOs (aus Blender) an gerechneten xyz-Positionen in einer aus Blender importierten, dort entworfenen Szene.

EyDu hat geschrieben:...Normalerweise würde ich auf abstraktere Bibliotheken wie Matplotlib, Mayavi, Pygame, oder Panda3D zurückgreifen

Genau das habe ich vor, weiss nur nicht, mit welcher Bibliothek ich sinnvollerweise mit Py3 arbeiten kann und das, was ich machen möchte, auch machen kann.

EyDu hat geschrieben:Wenn du unbedingt mit den gl*-Funktionen direkt arbeiten willst/musst, dann kannst du das auch gleich in C oder C++ machen und Python sparen.

Das mach ich ja im Moment auch so, zu Lernzwecken, mit einem OGL-Tutorial in C mit Geany.

EyDu hat geschrieben:Durchgesetzt hat sich mittlerweile OSG, da bekommt man von OpenGL nicht mehr viel mit.

Tja, das ist aber C++, das kann ich nicht ! Und ob ich da mit meinen C-Kenntnissen weiterkomme, wage ich, zu bezweifeln.

Weiß denn vielleicht jemand, wie man Processing2 unter Python installiert bekommt ? Unter https://pypi.python.org/simple/processing finde ich nur eine Python2-Version und wahrscheinlich auch nicht die Processing1 - Version.

Gerade habe ich mir überlegt, dass ich ja den Grafikteil in ein eigenes (Python27 -) Projekt packen und es per IP-Socket aus meinem Python3-Programm ansteuern könnte. Mit dem 2D-Java-Grafiken mache ich es ja auch schon genauso. Dann hätten sich erst mal alle Probleme mit Grafiken in Python3 erledigt. (Wieso bin ich eigentlich nicht schon früher auf die Idee gekommen ???)

Da ich mit diesem Thema nicht so recht weiterkomme, möchte ich es nochmal aufgreifen (und nicht nochmal als neues Thema posten).

Nachdem mein Programm nun als Zwitter (Python/Java) existiert und ich es auch schon benutze, ist mir klar geworden, dass es in dieser Form für mich keine Zukunft hat, weil mir das Programmieren mit Java einfach keinen Spass mehr macht. Da gibt zwar genau jetzt mit der Version 8 genau die Fähigkeiten, die ich gerade brauche, aber trotzdem gehe ich da nicht dran. Weil mir die Compiler-Läufe zu lange dauerten, habe ich sogar meinen 8 Jahre alten HP-Rechner ersetzt. Gut, es ist einfacher, ein Java-Programm unter einem anderen Betriebssystem ans Laufen zu bekommen, aber mit Python 3.4 habe ich es auch hinbekommen. Auf einem Mac-OSX-Rechner gab es gar keine Probleme, unter Windows7 musste ich aber erst ein Paket mit CMake und VS-Express zu einem pyd-Paket machen, wobei das neueste CMake mit Python 3.4 erst nach einem zusätzlichen Eintrag hierfür funktionierte.

Ein weiterer Punkt, der mich von einem weiteren Arbeiten mit Java abhält ist, dass mir die Darstellungsqualität (in allen BS, besonders in Windows) überhaupt nicht überzeugt. Das Font-Rendering und generell das Antialiasing ist schlecht und nur unzulänglich optimierbar. Mit Python gibt es damit keine Probleme: Wenn man die nativen Darstellungs-Einstellungen optimiert (unter Linux z.B. mit dem Infinility-Paket), wirkt sich das auch auf die Python-Pyside-Programme aus.

Ich hatte mit Python ja auch das Problem, dass es einige Grafik-Libs nur für Python2 gibt. Momentan habe ich das gelöst, indem ich meine Haupt-Datenstruktur per Socket an ein Python2-Programm übermittle, was mir aber mittlerweile überhaupt nicht mehr gefällt. Ich möchte gerne alles "aus einem Guß" haben, wie ich es schon immer gehalten habe. Aber mir ist auch aufgefallen, dass es sehr wichtig ist, sich auf eine Grafik-Bibliothek zu konzentrieren, die in der Community Anklang findet und aktiv weiterentwickelt wird. Das ist bei vielen nur in Python2 vorliegenden Libs nicht der Fall.

Bei Pyglet sieht es aber so aus, dass diese Bibliothek wohl recht beliebt ist und es hier wohl auch die Option gibt, sie mit Python3 zu programmmieren:

pyglet runs with Python 2.5+ and also with Python 3 through 2to3 tool (which
is executed automatically when installing).

BlackJack hatte schon angemerkt, dass es bei Pyglet keinen Eintrag für die Python-Version im Package-Index gibt und man es somit nicht mit Pip korrekt für Python3 installieren kann.

Jetzt habe ich pyglet mal aus Git herunter geladen und habe versucht, es mit setup.py install zu installieren. Hierbei gibt es aber das gleiche Problem wie mit pip: Das Paket wird zwar in pip list gelistet, funktioniert aber nicht, weil offensichtlich das 2to3 nicht darüber gelaufen ist.

Könnte mich da vielleicht jemand unterstützen ?

(... trotz, dass ich mich hier schon sehr unbeliebt gemacht habe )

Habe es hinbekommen ! Mit pip ging es nicht, downgeloaded und mit setup.py installiert, ging auch nicht. Selbst die normalerweise in Manjaro immer funktionierende Installation aus dem AUR per Octopi ging nicht.

Erst nachdem ich das tar aus dem AUR heruntergeladen habe und mit makepkg und anfolgendem pacman -U pygletxxx.pkg.tar.xz installiert habe, ging es !