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


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

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

From "Dr. Volker Jaenisch" <volker.jaenisch@inqbus.de>
Newsgroups de.comp.lang.python
Subject Re: [Python-de] Syntax-Erweiterung für Schleifen in Python3
Date 2016-04-06 21:06 +0200
Message-ID <mailman.36.1459971773.1197.python-de@python.org> (permalink)
References (3 earlier) <6E439C3C-FC40-4CAA-827C-8ACDE3DC85F2@zopyx.com> <57051734.6020207@thomas-guettler.de> <57051C5F.1080808@chrisarndt.de> <570553C5.80101@sschwarzer.net> <57055E23.40602@inqbus.de>

Show all headers | View raw


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
=========================================================

Back to de.comp.lang.python | Previous | Next | Find similar


Thread

Re: [Python-de]  Syntax-Erweiterung für Schleifen in Python3 "Dr. Volker Jaenisch" <volker.jaenisch@inqbus.de> - 2016-04-06 21:06 +0200

csiph-web