Wer arbeitet mit Python?

[Klinke]

Kannst du das Kompilieren des kompletten Codes nicht irgendwie forcieren? Evtl. gibt es ja einen Befehl dafür?

Ansonsten könntest du vielleicht beim Programm-Start irgendwas hinhacken was den entsprechenden Branch benutzt? (z.B. irgendeinen Dummy-Loop aufnehmen und gleich wieder löschen)

Es wiederspricht der Idee eines guten JIT compiler vor dem Start etwas zu kompilieren, da die während der Laufzeit gewonnen Information benutzt wird, um den VM-Code zu optimieren (nennt sich Dynamische Optimierung). Die Idee beim Programm-Start mal möglichst alle Branches aufzurufen, hatte ich auch mal, aber davor war ich dann doch zurückgeschreckt, vor allem da dies wegen der dynamischen Optimierung recht wenig garantiert.

Hmm, es werden ja diese ".pyc"-Dateien erzeugt, die den sog. "Bytecode" enthalten. Ich denke, die sind schon fertig kompiliert (wodurch es aber auch nicht viel schneller wird).

Die Standard Python Implementierung benutzt ja auch keine JIT. Gibt es allerdings auch für Python in Form von PyPy, welches aber leider nicht mit z.B. pandas kompatibel ist (für irgendwelche MIDI-Tools könnte es aber reichen, habe das allerdings nie getestet, halte eigentlich auch sehr wenig von Python, so dass ich mich in meiner Freizeit davon fern halte).

 

[Max]

besser schlecht kompiliert als gar nicht kompiliert zumindest die 3ms Pause solltest du so in den Griff bekommen...

vielleicht gibt es auch eine Möglichkeit, den kompilierten Code nach Programm-Ende nicht wegzuwerfen und beim nächsten Start wiederzuverwenden?

(sorry für OT)

 

[PySeq]

halte eigentlich auch sehr wenig von Python

Nanu, könntest Du kurz ausführen, warum? Magst Du generell interpretierte Skriptsprachen oder nur Python nicht?

 

[Klinke]

Nanu, könntest Du kurz ausführen, warum? Magst Du generell interpretierte Skriptsprachen oder nur Python nicht?

Ja, ich benutze lieber statisch getypte Sprachen, Scala ist dabei mein Favorit. Aber das ist nicht mein Hauptproblem, ich arbeite eigentlich auch ganz gerne mit R + tidyverse. Und vor den Entwicklern von Lua habe ich auch mein Respekt, wenn man sich damit beschäftigt merkt man, wie gut das durchdacht wurde. Am meisten stört mich wohl an Python die Weigerung gute Ideen funktionaler Programmiersprachen (vernünftig) zu integrieren. Z.B. sind die lambda Funktionen in Python ja echt ein Witz. Und list comprehension halte ich für deutlich unlesbarer und pflegbarer als map/filter Funktionen. Dazu kommt, dass ich in Python deutlich häufiger "What the fuck" Probleme habe, wenn ich mal exotischere Dinge probiere (z.B. Code der selbst neuen Code schreibt, ja einer der wenigen Vorteile von dynamischen Sprachen) als bei vielen anderen Sprachen (php und Javascript meine ich da z.B. nicht).

(und auch sorry für OT)

 

[einseinsnull]

Was genau?

Die geschweiften Klammern sind durch # auskommentiert und für den Interpreter komplett bedeutungslos.

wusstest du, dass das gegenteil von umständlich "ständlich" heißt?

das wort für das gegenteil ist also sogar kürzer wie das für das ungegenteil.

geheuerlich!

 

[bohor]

OK, ich fasse mal das (für mich) Allerwichtigste zusammen: Für MIDI- und ähnliche Anwendungen ist Python geeignet und wurde und wird verwendet. Für Audioanwendungen in real time hat es offenbar zuwenig Zugang zum Scheduling des Betriebssystems, auch scheint es da kein geeignetes Framework zu geben, das man dazu verwenden könnte. Zumindest aus Sicht der hier aktiven Forumsmitglieder, zumindest soweit ich euch verstanden habe.

Ich frag mich dann allerdings natürlich, wie Sprachen wie Max/MSP und pd das anstellen... : - )

 

[kris_]

Ich frag mich dann allerdings natürlich, wie Sprachen wie Max/MSP und pd das anstellen... : - )

Man kombiniert die Vorteile der verschiedenen Sprachen/Frameworks.

PD zumindest hat eine "Audio Engine", die für die Echtzeitverarbeitung gemacht ist. Pure Data ist zum Großteil in C geschrieben, also recht Maschinen-nah (https://github.com/pure-data/pure-data sagt ca 82% C Source Code). Das macht Sinn, einige Alternativen zu C für diesen Zweck haben wir hier im Thread gehabt, C++, Faust, SOUL, ...

Da die Arbeit in C mit so einer Engine aber eher mühsam sein kann, legt man dann eine Abstraktionsschicht drüber - bei PD scheint das (ich habe es noch nicht benutzt) eine proprietäre Syntax zu sein, deren Erstellung durch UI Tools vereinfacht wird. In dieser höheren Abstraktionsschicht programmiert man dann eher per "Konfiguration" der Engine, die eigentlich Verarbeitung der mathematischen Operationen der einzelnen Samples wird aber durch den schnelleren Code in der Engine durchgeführt.

Ich vermute, Max macht das ähnlich. Diese Architektur findet man in sehr vielen Systemen zur Datenverarbeitung, bspw. auch in Datenbanken, wo mein Operationen auf großen Datenmengen in einer eigenen Sprache wie SQL formuliert, aber die tatsächlichen Operationen durch hochoptimierten Code innerhalb der "Datenbank-Engine" durchgeführt werden.

 

[bohor]

Danke.

Soweit in der Theorie ist mir das schon klar. Allerdings kommt einmal im Jahr eine neue Betriebssystemversion für den Mac raus, und fast so häufig für Windows und für Linux. Da frag ich mich, ob es dort wirklich nie Änderungen am Unterbau gibt, so dass pd und Max auch weiter klaglos laufen.

 

[PySeq]

Allerdings kommt einmal im Jahr eine neue Betriebssystemversion für den Mac raus, und fast so häufig für Windows und für Linux. Da frag ich mich, ob es dort wirklich nie Änderungen am Unterbau gibt, so dass pd und Max auch weiter klaglos laufen.

Zu Linux kann ich sagen, daß da von Betriebssystemseite "alsa" läuft ("Advanced Linux Sound Architecture"). Das gibt es seit 1998 und ist heute immer noch aktiv (trotz einiger Versuche, es zu verschlimmbessern).

 

[tux]

Älter und weniger elegant als Python ist Perl (dafür weniger streng und etwas freier in der Syntax). Ansonsten kann man damit praktisch das Gleiche erreichen.

Ja das kann ich bestätigen, sämtliche Synth Editors die ich bisher geschrieben habe sind in reinem Perl geschrieben, (GUI in Perl-Tk).

Perl ist so elegant oder unelegant wie man möchte, da ist man sehr frei.
Hatte mal folgendes zu Python vs. Perl gelesen: "Python is like Perl in a straight-jacket".

 

[2bit]

Not macht erfinderisch:




Habe festgestellt, dass mir durch den Wechsel von der Maus zum Stift+Zeichenpad elementare Funktionen verloren gegangen sind:

Horizontales + vertikales Scrolling, Rotation der Arbeitsfläche, Rein- & Rauszoomen werden nun mit der linken Hand per Novation Launchpad MK2 abgefrühstückt. Das sind alles Keyboard+Mouse-Shortcuts, die ich nachgebaut und dann mir dann selbst per Tastendruck auf das Launchpad zur Verfügung gestellt habe.

Die Software dahinter ist Python3 geschrieben, unter anderem mit folgenden zusätzlichen Modulen:

mido
Pillow
numpy
pynput

Ich hab mir vor einigen Monaten selbst ne kleine API für das Launchpad geschrieben, mit der ich unter anderem 8x8 Pixel große RGB-BMPs einlesen (per Pillow & Numpy in Zahlen umgewandelt, die das Launchpad verstehen kann) und direkt auf dem Launchpad (Midi: Noten, CC und Sysex werden per mido geregelt) darstellen kann. Das ist alles sehr unaufgeräumt und funktioniert irgendwie. Python verleitet einen zu echt schludrigen Arbeitsweisen, bei der man alles irgendwie in Dateien reinmüllt und irgendwann fängt man aus lauter Faulheit an, unleserliche Abkürzungen zu verwenden. Man merkt hier ganz deutlich, dass Objektorientierung ohne vernünftige Namespaces und saubere Datenkapselung ziemlicher Schwachsinn ist.

 

[noir]

Python verleitet einen zu echt schludrigen Arbeitsweisen, bei der man alles irgendwie in Dateien reinmüllt und irgendwann fängt man aus lauter Faulheit an, unleserliche Abkürzungen zu verwenden. Man merkt hier ganz deutlich, dass Objektorientierung ohne vernünftige Namespaces und saubere Datenkapselung ziemlicher Schwachsinn ist.

Immer hin alles ordentlich formatiert!!!11

 

[haebbmaster]

voll abgefahren!

 

[DrMickey]

Python verleitet einen zu echt schludrigen Arbeitsweisen, bei der man alles irgendwie in Dateien reinmüllt und irgendwann fängt man aus lauter Faulheit an, unleserliche Abkürzungen zu verwenden. Man merkt hier ganz deutlich, dass Objektorientierung ohne vernünftige Namespaces und saubere Datenkapselung ziemlicher Schwachsinn ist.

Mit Verlaub, das finde ich quatsch. Du kannst in (fast) jeder Programmiersprache schusseln und schludern. Selbst in PHP kann man ordentlich programmieren — ja, nur wenige machen es, das liegt aber nur ein bisschen an PHP an sich. Ggfs. unterstützt bzw. zwingt Dich die eine oder andere Sprache mehr zu sauberem Code, aber am Ende des Tages ist die Architektur eine Funktion Deiner Kenntnisse und Deiner Selbstdisziplin. Schau Dir mal ein paar große Frameworks in Python an, Twisted, numpy oder Tensorflow, die wären nicht so erfolgreich, wenn Python eine inhärent schludrige Arbeitsweise fördern würde.

 

[2bit]

Selbstdisziplin

Aha.
Selbstdisziplin ist böse, wenn es um Whitespaces und Klammern geht. Da hat man sich ja nicht entblödet, einem eine ganz bestimmte Syntax mit aller Gewalt aufzunötigen. Aber sobald man an den Innereien von fremden Modulen herumpfuschen kann oder sich Dank LEGB beim Refaktorieren fürchterlich mit Variablennamen verhaspelt, braucht man bloß nicht auf die Idee kommen, dass irgendwelche Konventionen (=nur so gemeint, aber nicht wirklich vom Interpreter durchgesetzt) einem dann weiter helfen.

Irgendwann hatte ich schlicht und ergreifend keine Lust mehr auf diese bizarren Coderückespielchen. Code funktioniert -> sofort auslagern und per import referenzieren, bevor der wieder kaputteditiert wird und man stundenlang den Fehler sucht. Und der Gag ist: Ein Modul muss gar keine Klasse sein. Etwaig vorhandener Code wird beim Import sofort ausgeführt.

 

[D1g1t4l D3t0x3r]

Ich arbeite seit 2017 mit Python, beruflich und privat, davor war Perl meine Hauptsprache. Mein Synthesizer-Projekt Sompyler hat zwei wesentliche Zwecke gehabt, nämlich, mir Python beizubringen, und mir Musik auf eine Weise beizubringen, die viele Synergien mit bestehendem Wissen nutzt, eben auf nerdige Art. Leider muss ich damit auf eine Community verzichten, denn Software, die ich quasi als Erweiterung meines Kopfes programmiert habe, und Usabiltytests mit anderen nie stattfanden, ist logischerweise nicht markttauglich. "Der Markt" will intuitiv bedienbare Oberflächen, Echtzeitfähigkeit und Interoperabilität mit anderen Geräten und Programmen, in allen drei Hinsichten ist meine Software ein Non-match. Erspart mir Support und Umgang mit Menschen, brrrrr.

Heute verwende ich sie am liebsten, um Klavierliteratur, die ich eh noch nicht motorisch beherrsche, umzusetzen, direkt vom analogen Blatt. Ich kodiere sie um in die Sprache, die das Programm versteht, definiere geeignete (Nicht-Klavier-)Klänge ebenfalls von Grund auf, in Textform, und starte das Programm. Es liest den Text ein und bringt das System ordentlich ins Schwitzen, und am Ende, nach meinem achtsamen Genuss lieblicher Vorfreude bei fingertrommelnder Beobachtung eines Fortschrittbalkens purzelt eine Audiodatei heraus. Die hör ich mir im VLC an. Für gut befunden, geb ich sie anderen zu hören, sammle BHs und Blumen von der Bühne ein nehme Kritik an, die früher oder später ja doch durch mein pralles Ego durchdestilliert ist und versuche es besser zu machen.

Und wer sich an den Einrückungen bei Python stört, sollte seine Programme besser strukturieren. Oder eine gescheite IDE verwenden.

 

[2bit]

Und wer sich an den Einrückungen bei Python stört, sollte seine Programme besser strukturieren. Oder eine gescheite IDE verwenden.

Mache ich ja. Führt halt zu bizarren Dateistrukturen, damit ne einigermaßen komplexe Anwendung noch zu handhaben ist. Und da du das Strukturieren ansprichst: Hab ich schon erwähnt, dass ich es total banane finde, dass man ne 08/15-Switch selber neu implementieren muss, weil diese Kontrollstruktur gar nicht teil des Sprachstandards ist? Hab ich am Ende nicht gemacht, ein Haufen IFs tut's auch...

Der Vollständigkeit halber das Python-Konvolut zur Switch: https://entwickler.de/online/python/switch-case-statement-python-tutorial-579894245.html

 

[D1g1t4l D3t0x3r]

Man braucht ein Programm nicht notwendig in Dateien aufsplitten. Überschaubare Funktionen und Methoden helfen bereits, Einrückungsebenen zu reduzieren.

 

[2bit]

Man braucht ein Programm nicht notwendig in Dateien aufsplitten.

Das sagst du nicht mehr, wenn du mal ne längere Zeit per SSH und nano an nem Pythonscript gefrickelt hast. Zwei Secure Shells, die auf zwei verschiedene Dateien eines Projekts zeigen, lassen sich schnell aufbauen. Aber ein und dieselbe Datei zeitglich von zwei Nano-Instanzen zu bearbeiten, ist sehr uncool, weil das nämlich zu Chaos führt.

 

[Klinke]

Der Vollständigkeit halber das Python-Konvolut zur Switch: https://entwickler.de/online/python/switch-case-statement-python-tutorial-579894245.html

Ein sehr schönes Beispiel dafür, was mich an der Python-Community so ankotzt: Da wird dann wieder so getan, als ob der "pythonic" way ja sowieso der besser sei, dabei kennt natürlich (fast) jede andere Programmiersprache auch Dictionaries und kann für einen der ganz selten Fälle, dass man tatsächlich einen dynamisches Switch braucht, diesen darüber implementieren.

 

[D1g1t4l D3t0x3r]

Das sagst du nicht mehr, wenn du mal ne längere Zeit per SSH und nano an nem Pythonscript gefrickelt hast. Zwei Secure Shells, die auf zwei verschiedene Dateien eines Projekts zeigen, lassen sich schnell aufbauen. Aber ein und dieselbe Datei zeitglich von zwei Nano-Instanzen zu bearbeiten, ist sehr uncool, weil das nämlich zu Chaos führt.

Nano würde ich allenfalls für kleine Änderungen an einer einzelnen Datei verwenden. Für größeres verwende ich VIM. Der kann spielend zwei Fenster auf dieselbe Datei ansetzen - und synchron halten. Gut, man braucht Zeit, sich darin einzuarbeiten.

 

[tichoid]

Mache ich ja. Führt halt zu bizarren Dateistrukturen, damit ne einigermaßen komplexe Anwendung noch zu handhaben ist. Und da du das Strukturieren ansprichst: Hab ich schon erwähnt, dass ich es total banane finde, dass man ne 08/15-Switch selber neu implementieren muss, weil diese Kontrollstruktur gar nicht teil des Sprachstandards ist? Hab ich am Ende nicht gemacht, ein Haufen IFs tut's auch...

Der Vollständigkeit halber das Python-Konvolut zur Switch: https://entwickler.de/online/python/switch-case-statement-python-tutorial-579894245.html

ich bin absoluter Python-Anfänger, habe bisher nur bisschen PHP gemacht. Jetzt habe ich mir das durchgelesen und meine Frage dazu: Könnte man das Problem des fehlenden Switches nicht einfacher mit einem Array lösen?
-> https://www.w3schools.com/python/python_arrays.asp

 

[Klinke]

ich bin absoluter Python-Anfänger, habe bisher nur bisschen PHP gemacht. Jetzt habe ich mir das durchgelesen und meine Frage dazu: Könnte man das Problem des fehlenden Switches nicht einfacher mit einem Array lösen?
-> https://www.w3schools.com/python/python_arrays.asp

In Spezialfällen, ja. Aber im allgemeinen können switches auch mal auf Strings testen, also die Form:
switch(a) {
case "foo":
...

haben, dann brauchst Du auf jeden Fall ein Dictonary. Ausserdem gibt es bei der Implementierung von switch statements auch eine default Option, also:
switch(a) {
case "foo":
...
default:
...
}

welche in dem Beispiel immer der zweite Parameter bei dem get auf das Dictonary ist.

Edit: Zum Glück sind meine Code-Fragmente nicht Python, ansonsten müßte ich mich ja jetzt erstmal schlau machen, wie ich es schaffe, dass die Einrückungen im Code nicht automatisch beim posten entfernt werden

 

[zenobic]

Und wer sich an den Einrückungen bei Python stört, sollte seine Programme besser strukturieren. Oder eine gescheite IDE verwenden.

Ich verwende auch ab und zu Python und kann sagen dass eine IDE zwar vieles abfangen kann, aber ich auch schon über ein Fall gestolpert bin, bei dem mich das "whitespace-sensitive Scoping" eine Anweiung versehentlich in ein `if`-Block packen ließ, als ich nur mal was auskommentiert habe.Das Skript lief nicht unter test, sonst wäre das direkt aufgefallen. Es ist zum Glück nichts schlimmeres passiert.

ich bin absoluter Python-Anfänger, habe bisher nur bisschen PHP gemacht. Jetzt habe ich mir das durchgelesen und meine Frage dazu: Könnte man das Problem des fehlenden Switches nicht einfacher mit einem Array lösen?

Je nach Anwedungsfall kann auch ein IF oft anhand einer Map aufgelöst werden. Aber, ich würde gar nicht in diesem Kontext weiter darüber nachdenken, das sind keine Python-Probleme. Dinge wie GIL etc. sind schon eher diskutable.

 

[D1g1t4l D3t0x3r]

Edit: Zum Glück sind meine Code-Fragmente nicht Python, ansonsten müßte ich mich ja jetzt erstmal schlau machen, wie ich es schaffe, dass die Einrückungen im Code nicht automatisch beim posten entfernt werden

if XenForo.has_feature("verbatim code blocks"):
    print("Yes, and they are really covering a multitude of languages, even Python.")
else:
    print("I wouldn't be here, probably")

 

[noir]

Kennt sich hier eigentlich jemand mit Qt für Python ergo Pyside aus? Qt ist für mich Neuland und die Doku ist ziemlich beschissen...

 

[e6o5]

Ist schon etwas her. Aber war eigentlich ziemlich straightforward. Wo brauchst du Hilfe?

 

[noir]

Wo brauchst du Hilfe?

Ich implementiere die PC App für den Oxi One und habe dafür angefangen PySide6 zu lernen. Aktuell verlier ich mich in der wunderbaren Welt des Threadings. Das Ganze ist Open Source: https://gitlab.com/manuwind5/Oxi-Desktop-App/-/tree/pyside6
Konkret gibt's einen Thread der auf MIDI Daten des Oxi wartet und diese verarbeitet bzw. Signals senden soll. Das ganze ist in der OxiHardware.py implementiert.
Nach vielem Fluchen hab ichs halbwegs am Laufen, aktuell frage ich mich:
- wie ich sauber aus dem MidiLoop Thread wieder raus komme. Momentan muss ich das Ding hart killen.
- wie ich am saubersten die Signale des Threads mit den Signalen für die GUI verbinde. Muss der Umweg über self.__setVersion sein?
- (nicht Qt spezifisch) wie ich das Parsen der MIDI Daten sauberer lösten könnte. Mit dem jetzigen Architektur würde es eine längere Kette von if msg.bin().startswith(ReceiveMessages.FOOBAR): geben. Andernteils muss es natürlich so schnell wie möglich sein.

Aber ich sehe schon 4293 weitere Probleme auf mich zu kommen

 

[SynthGate]

die Programmiersprache sollte bei so gut wie jeder MIDI-Anwendung ziemlich egal sein

Ja, wenn es um Ausführungsgeschwindigkeit geht, nein, wenn es um modernen, einfach lesbaren Code geht. Da ist Python weit vorne.

 

[SynthGate]

Whitespaces als Syntaxstrukturelement ist die Seuche...

Dieser Blödsinn wird immer wieder behauptet, und trotzdem hatte ich in 7 Jahren massiven Python-Gebrauchs nur einmal ein Problem damit, was nach 10 Minuten behoben war. Und dafür 7 Jahre keine Klammern, die entweder Zeilen fressen oder einfach nur doof aussehen ("} else {").