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

Path csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
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 Wed, 6 Apr 2016 22:56:34 +0200
Lines 127
Message-ID <mailman.41.1459976398.1197.python-de@python.org> (permalink)
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> <CFBF51AE-8293-46DF-9173-938C63383B89@darwin.in-berlin.de>
Mime-Version 1.0 (1.0)
Content-Type text/plain; charset=utf-8
Content-Transfer-Encoding quoted-printable
X-Trace news.uni-berlin.de 0K5cjm1ivYyxdcYujhb1MgsVAIXdYZ/wIIw9KTuR9kHQ==
Return-Path <gherman@darwin.in-berlin.de>
X-Original-To python-de@python.org
Delivered-To python-de@mail.python.org
X-Envelope-From gherman@darwin.in-berlin.de
X-Mailer iPhone Mail (12B440)
In-Reply-To <57055E23.40602@inqbus.de>
X-BeenThere python-de@python.org
X-Mailman-Version 2.1.21
Precedence list
List-Id Die Deutsche Python Mailingliste <python-de.python.org>
List-Unsubscribe <https://mail.python.org/mailman/options/python-de>, <mailto:python-de-request@python.org?subject=unsubscribe>
List-Archive <http://mail.python.org/pipermail/python-de/>
List-Post <mailto:python-de@python.org>
List-Help <mailto:python-de-request@python.org?subject=help>
List-Subscribe <https://mail.python.org/mailman/listinfo/python-de>, <mailto:python-de-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID <CFBF51AE-8293-46DF-9173-938C63383B89@darwin.in-berlin.de>
X-Mailman-Original-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>
Xref csiph.com de.comp.lang.python:4360

Show key headers only | 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