Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comp.lang.python > #4360
| From | Dinu Gherman <gherman@darwin.in-berlin.de> |
|---|---|
| Newsgroups | de.comp.lang.python |
| Subject | Re: [Python-de] Syntax-Erweiterung für Schleifen in Python3 |
| Date | 2016-04-06 22:56 +0200 |
| Message-ID | <mailman.41.1459976398.1197.python-de@python.org> (permalink) |
| References | (4 earlier) <57051734.6020207@thomas-guettler.de> <57051C5F.1080808@chrisarndt.de> <570553C5.80101@sschwarzer.net> <57055E23.40602@inqbus.de> <CFBF51AE-8293-46DF-9173-938C63383B89@darwin.in-berlin.de> |
Hallo Volker & Co.! Danke Dir und anderen für diesen und ähnlich konstruktiven Beiträge! Deswegen gibt es diese und ähnliche Listen, damit man weitergibt und/oder weiterkommt, und nicht, um dumpfbackiges Gedöns abzusondern und anderen permanent Platzverweise und Maulkörbe zu erteilen. Gruß, Dinu Am 06.04.2016 um 21:06 schrieb Dr. Volker Jaenisch <volker.jaenisch@inqbus.de>: > > Servus Thomas! > >> Am 06.04.2016 um 20:21 schrieb Stefan Schwarzer: >> - Bevor man über Syntax-Erweiterungen nachdenkt, sollte man >> meines Erachtens erst mal schauen, ob man nicht eine >> Möglichkeit findet, diese Schleifen-Sonderfälle mit einer >> jetzt schon funktionierenden Python-API zu behandeln. Es >> kann natürlich sein, dass das schwerfällig wird, aber ich >> finde es besser, das auszuprobieren als es nur zu >> vermuten. :-) > Wie wahr und zutreffend Stefan! > Ich mache seit mehr als 20 Jahren Performance-Optimierung von Code in > Python. > > Das genannte Beispiel > > connection = get_db_connection() > for item in my_iterator: > push_item_to_db(item, connection) > > und der Vorschlag wegen der Rechenzeit für das teure Öffnen der > DB-Connection die Syntax des Interpreters ändern zu wollen > ist absurd. Es mag ja wenige akademische Spezialfälle geben in denen so > etwas evtl. weniger Rechenzeit benötigt. In "real world" Szenarien > hat man sowieso nicht eine DB-Verbindung sondern einen Pool von > DB-Verbindungen, da wirkliche Performance heutzutage nur mit > Parallelisierung erreichbar ist. > Es ist also viel interessanter eine Schleife und deren Inhalte auf > mehrere CPUs zu verteilen als Corner-Cases am Anfang der Schleife zu > optimieren. > > Ansonsten ist dies wieder einer der Fälle in denen vergessen wird, dass > man viele solcher Probleme > durch das gesonderte Behandeln des ersten oder des letzten > Schleifen-Elements einfach in den Griff bekommt. > > try: > first_item = my_iterator.next() > > connection = get_db_connection() > push_item_to_db(first_item, connection) > > except StopIteration: > ->> Exit oder continue oder break > > for item in my_iterator: > push_item_to_db(item, connection) > > Sagte, da gerade jemand, dass dies uneleganter Code ist, den man mit der > neuen Syntax viel kompakter etc. hinschreiben könnte? > Wenn es wirklich um Performance geht ist es nahezu unvermeidbar auch mal > hässlichen Code zu schreiben - oder Cython oder C zu verwenden was > letztlich > nur bedeutet dem Schreiben von hässlichem Code einen neuen Namen zu > verpassen. Das bedeutet aber im Umkehrschluss nicht, dass man den > hässlichen Code, > wie Du es Dir vorstellst mit Gewinn einfach im Interpreter verstecken > kann. Denn .. > > .. Du schlägst mit >> - on-empty >> - pre-first (siehe oben) >> - on-break (wie bisher "else") > drei zusätzliche Exits zum For-Konstrukt vor. IMHO zeichnet sich eine > gute Programmiersprache unter anderem durch Ihre Orthogonalität und > Einfachheit aus. > Aus einfachen Konstrukten werden größere Konstrukte aggregiert. Wenn man > aber anfängt die Konstrukte auf der untersten Ebene komplizierter zu > machen erzeugen > diese zusätzlichen Freiheitsgrade Probleme bei der Optimierung. Ein JIT > wie PyPy kann Python-Schleifen prima optimieren, eben weil sie einfach > sind. Machen wir Python-Schleifen > komplizierter, wird die Optimierung komplizierter und damit weniger > effizient. Der Gewinn bei Deinen Corner-Cases wird durch die > wegfallenden Optimierungsmöglichkeiten sofort wieder aufgefressen. > > Ein weiterer Denkanstoß: Bis heute werden numerische Bibliotheken in > Fortran77 gepflegt und viel Code in den Wissenschaften wird sogar noch > in F77 geschrieben obwohl Fortran uralt ist. > Der Grund dafür ist unter anderem, dass Fortran77 so simpel ist. Daher > kann Fortran mit optimierenden F2C-Compilern sehr stark optimiert und > parallelisiert werden. Auch kann der Code durch automatisierte Verfahren > auf seine Richtigkeit getestet werden. Die Einfachheit der Konstrukte > von F77 verhinderte es komplizierten Code überhaupt hinzuschreiben. > Daher war es möglich über Jahrzehnte hinweg den Code der numerischen > Bibliotheken nahezu fehlerfrei zu bekommen. > > Beste Grüße > > Volker > > -- > ========================================================= > inqbus Scientific Computing Dr. Volker Jaenisch > Richard-Strauss-Straße 1 +49(08861) 690 474 0 > 86956 Schongau-West http://www.inqbus.de > ========================================================= > > > _______________________________________________ > python-de maillist - python-de@python.org > https://mail.python.org/mailman/listinfo/python-de
Back to de.comp.lang.python | Previous | Next | Find similar
Re: [Python-de] Syntax-Erweiterung für Schleifen in Python3 Dinu Gherman <gherman@darwin.in-berlin.de> - 2016-04-06 22:56 +0200
csiph-web