Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.python > #4360

Re: [Python-de] Syntax-Erweiterung für Schleifen in Python3

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>

Show all headers | View raw


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


Thread

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