Path: csiph.com!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: "Dr. Volker Jaenisch" <volker.jaenisch@inqbus.de>
Newsgroups: de.comp.lang.python
Subject: Re: [Python-de] =?utf-8?q?Syntax-Erweiterung_f=C3=BCr_Schleifen_in_P?= =?utf-8?q?ython3?=
Date: Wed, 6 Apr 2016 21:06:11 +0200
Lines: 108
Message-ID: <mailman.36.1459971773.1197.python-de@python.org>
References: <57040A52.9020404@thomas-guettler.de> <F355D502-7753-4583-AABF-325BB68D2143@zopyx.com> <5704A110.4030006@behnel.de> <6E439C3C-FC40-4CAA-827C-8ACDE3DC85F2@zopyx.com> <57051734.6020207@thomas-guettler.de> <57051C5F.1080808@chrisarndt.de> <570553C5.80101@sschwarzer.net> <57055E23.40602@inqbus.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.0
In-Reply-To: <570553C5.80101@sschwarzer.net>
Precedence: list
Xref: csiph.com de.comp.lang.python:4358

Servus Thomas!

Am 06.04.2016 um 20:21 schrieb Stefan Schwarzer:
> - Bevor man =FCber Syntax-Erweiterungen nachdenkt, sollte man
>   meines Erachtens erst mal schauen, ob man nicht eine
>   M=F6glichkeit findet, diese Schleifen-Sonderf=E4lle mit einer
>   jetzt schon funktionierenden Python-API zu behandeln. Es
>   kann nat=FCrlich sein, dass das schwerf=E4llig 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 =3D get_db_connection()
    for item in my_iterator:
        push_item_to_db(item, connection)

und der Vorschlag wegen der Rechenzeit f=FCr das teure =D6ffnen der
DB-Connection die Syntax des Interpreters =E4ndern zu wollen
ist absurd. Es mag ja wenige akademische Spezialf=E4lle geben in denen so=

etwas evtl. weniger Rechenzeit ben=F6tigt. 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=E4lle 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 =3D my_iterator.next()

    connection =3D 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=F6nnte?
Wenn es wirklich um Performance geht ist es nahezu unvermeidbar auch mal
h=E4sslichen Code zu schreiben - oder Cython oder C zu verwenden was
letztlich
nur bedeutet dem Schreiben von h=E4sslichem Code einen neuen Namen zu
verpassen. Das bedeutet aber im Umkehrschluss nicht, dass man den
h=E4sslichen Code,
wie Du es Dir vorstellst mit Gewinn einfach im Interpreter verstecken
kann. Denn ..

=2E. Du schl=E4gst mit
>  - on-empty
>  - pre-first (siehe oben)
>  - on-break (wie bisher "else")
drei zus=E4tzliche Exits zum For-Konstrukt vor. IMHO zeichnet sich eine
gute Programmiersprache unter anderem durch Ihre Orthogonalit=E4t und
Einfachheit aus.
Aus einfachen Konstrukten werden gr=F6=DFere Konstrukte aggregiert. Wenn =
man
aber anf=E4ngt die Konstrukte auf der untersten Ebene komplizierter zu
machen erzeugen
diese zus=E4tzlichen 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=F6glichkeiten sofort wieder aufgefressen.

Ein weiterer Denkansto=DF: 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=FCr 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 =FCberhaupt hinzuschreiben.
Daher war es m=F6glich =FCber Jahrzehnte hinweg den Code der numerischen
Bibliotheken nahezu fehlerfrei zu bekommen.

Beste Gr=FC=DFe

Volker

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
   inqbus Scientific Computing    Dr.  Volker Jaenisch
   Richard-Strauss-Stra=DFe 1       +49(08861) 690 474 0
   86956 Schongau-West            http://www.inqbus.de
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D