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

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

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

Show all headers | View raw

Servus Sven!

Am 07.04.2016 um 00:38 schrieb Sven R. Kunze:
>
> Es geht darum, die Zukunft zu gestalten. Nicht, anderen zu sagen, dass 
> ihre Umsetzungsvorschläge anders aussehen sollten, und eigentlich 
> alles ganz einfach ist.
Mh. Darüber wie die Zukunft von Python zu gestalten ist weis ich wenig. 
Ich habe schlicht das Argument von Thomas aufgenommen und meine Meinugn 
dazu gepostet, da ich denke, dass sein Argument nicht schlüssig ist. 
Eine Zukunft auf nicht schlüssigen Argumenten aufzubauen ist sicher 
nicht gut.
>
> Das ist es nämlich nicht, weil eben gerade die Vielfalt an 
> Lösungsalternativen, die nebenbei bemerkt nie 100% funktionieren, ein 
> sehr gutes Indiz dafür sind, hier etwas bewegt werden sollte. Von 
> daher finde ich es gut, wenn Thomas Vorschläge bringt. Die Länge des 
> Threads und die Vorschläge auf python-ideas waren bemerkenswert und 
> selbst auf python-de wurden gute Impulse gesetzt; DIE, wohl gemerkt, 
> mehr für das Inkludieren in die Sprache sprechen als dagegen. Die 
> Diskussion ist ergebnisoffen und sowohl ein Ablehnen als auch ein 
> Zustimmen bedürfen sehr guter Argumente.
Ich habe Thomas Argument mit einer fairen Gegenargumentation entgegnet. 
Was soll ich Deiner Meinugn nach noch tun um konstruktiv zu diskutieren?
>
>> 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)
>>
>
> Es scheint mir so, als wäre Python dann nichts für dich. Frühe 
> Versionen von Assembler wäre wohl deinen Anforderungen besser 
> geeignet, da sie noch nicht so viel Komfort-Mnemonics erlaubten.
Warum flamest Du mich so an? Das Argument von Thomas war Performance. 
Ich mache Performance und ja, ich setze zur Not auch Assembler dafür 
ein. Aber das gibt Dir nicht das Recht mir die Nutzung von Python 
abspenstig zu machen. Ich nutze Python sehr lange und weis was ich daran 
habe: Eine langsame komfortable Hochsprache in welcher ich performanten 
Code aus anderen Sprachen einbinden kann. Wenn ich auch nur 100.000 
Schleifendurchläufe habe, werde ich die nie in Python realisieren 
sondern in Cython oder C - daran wird auch ein neues For-Konstrukt für 
Corner-Cases nichts ändern.
> Einfachheit und Komfort sind das Wichtigste und in genau diesem 
> Bereich lässt Python bezüglich Schleifen ein wenig zu wünschen übrig. 
> Da sind andere Sprachen schon weiter.
Einfachheit ist evtl. genau das was Du und ich unter Orthogonalität 
verstehen. Aber ich bin mir sehr sicher, dass Komfort und Performance 
ein Gegensatz-Paar bilden.
>
> Ein kleines und zugegebenermaßen extremes Beispiel. Wenn man deiner 
> Argumentation folgt, dann brauchen wir kein "if". Um dich damit zu 
> zitieren:
>
> "[Hier ist es auch] wieder einer der Fälle in denen vergessen wird, 
> dass man viele solcher Probleme durch [die Verwendung einer besonderen 
> while-Schleife] einfach in den Griff bekommt."
Ich glaube Du hast mich hier missverstanden. Es ging mir darum meinem 
Vorredner Stefan Schwarzer recht zu geben, dass sich das vorgestellte 
Problem durch eine einfache Art und Weise in Python lösen läßt.

> In anderen Worten: korrekter Kontrollfluss, der alle Randfälle 100% 
> beachtet, ist sehr sehr schwer umzusetzen für die meisten Entwickler. 
> Kommen dann noch Konzepte wie Nebenläufigkeit und gemeinsamer Zustand 
> hinzu, sind sehr viele verloren. Dich, Volker, betrifft das natürlich 
> nicht, weil du, wie du weiter unten ausführst, Nebenläufigkeit und 
> Kontrollfluss fehlerfrei handhabst.
Sorry, aber Du wirst nie durch eine erweiterte API die Programmierfehler 
von Anfängern beseitigen. Die von Dir angesprochenen Probleme der 
Nebenläufigkeit und des Kontrol-Flusses werden immer so weit oberhalb 
der Python-API liegen, dass die API dort wohl kaum Abhilfe schaffen kann.
>
> Ist deine angepriesene Lösung thread-safe?
Warum sollte Sie das nicht sein? Sie ist mit Sicherheit genauso 
Thread-Save wie:

connection = get_db_connection()
for item in my_iterator:
push_item_to_db(item, connection)

Aber waren wir nciht gerade bei der Diskussion um Performance. 
Performance und Threads passt unter Python nicht so recht zusammen. 
Performance und Tasks schon eher. Und damit stribt Dein Thread-Argument.

> Warum ist der try-Block eigentlich so groß? -> Was passiert, wenn 
> "get_db_connection", "push_item_to_db" eine StopIteration wirft? 
> (unbeabsichtigt, wir machen alle Fehler, richtig?)
Mh. Das sind einige sehr provokative Fragen. Ich entgegne mal mit einer 
Gegenfrage. Wenn es tatsächlich diese drei zusätzlichen Exit-Handler 
gäbe. Was würden die neue For-Schleife mit einem fälschlichen 
"StopIteration" machen?
Das Verlagern von Python-Code in die Python-API ändert nichts an dessen 
Problemen.

>
> Automatisches Optimieren geht umso besser, um so mehr semantisch 
> eindeutige Information vorhanden ist. Würde man den Kontrollfluss 
> manuell, wie du ihn und andere vorgeschlagen haben, umsetzen, hätte 
> der JIT-Compiler keinen blassen Schimmer, was ihm der Programmierer 
> damit sagen wollte (Halte-Problem etc.). Wird diese aber in semantisch 
> definierte Syntax gegossen, dann sind plötzlich völlig neue 
> Möglichkeiten der Optimierung gegeben. Der Compiler *weiß* plötzlich, 
> was der Quellcode *bedeuten soll* und kann entsprechend noch mehr 
> optimieren.
>
> Schade, dass du das Potenzial hier verkennst.
Ich verstehe und akzeptiere Dein Argument. Nur Semantik ist nicht alles 
- Komplexität ist auch ein nicht zu unterschätzender Feind. Wenn der JIT 
an der Komplexität stirbt, weil er nicht tief genug analysieren kann, 
weil zu komplex, ist auch niemandem geholfen.
Daher gebe ich Dir recht: Es ist nicht so schwarz-weiss, wie ich es 
gezeichnet habe.

Trotzdem finde ich die Argumentation mit der Performance nicht 
angemessen, was auch Dir schon klar zu sein scheint, weil Du die 
zusätzlichen Argumente "Komfort" und "Schutz der Anfänger die alle das 
Rad neu erfinden müssen" einbringst. Also zwei neue Argumente, die 
nichts mit der ursprünglcihen Diskussion um "Performacne" zu tun haben.

Auf welcher Grundlage wollen wir also weiter diskutieren? Auf der der
1) Performance
2) Komfort
3) Anfänger vor Fehlern bewahren

Ich halte weder 2) und 3) für zielführend.
Bei der Performance-Debatte würde ich Dich (oder Thomas) bitten mal die 
PyPy-Leute fragen, ob die Deiner Meinung bezüglich der Sementik sind. 
Wenn die PyPy-Leute wirklich das neue FOR-Konstrukt besser auswerten 
können (und wollen) könnte es Sinn machen es in die API zu 
implementieren. Wenn dies der Fall wäre könnt Ihr sofort auf meine 
Stimme zählen.

Trotzdem stehe ich zu meiner Argumentation von oben:
Wenn ich 100.000 Loop-Durchläufe habe dann ist nicht die For-Schleife im 
innersten Loop das Problem, die manchmal nicht durchlaufen wird.
Dann muss man eben das Rad (neu) erfinden, damit sich der Code dreht. 
Das ist immer abhängig von vielen Randbedingungen und die kann die 
Python-API nicht generisch lösen.

Meine Erfahrung ist, dass die wirklichen Performance-Probleme i.d.R. 
weit oberhalb der API auftreten oder so tief unten, dass sie am besten 
mit Cython&Co optimiert werden.
Performance-Probleme mit Python an sich habe ich eigentlich nie. Oder 
anders formuliert: Wenn ich mit Python performance-Probleme bekomme dann 
löse ich sie oberhalb der API oder unterhalb - denn beides ist
weitaus performanter als eine Änderung des Interpreters. Man kann z.B: 
SQL-Abfragen oder Dateizugriffe in einem verteilten Dateisystem um 
Größenordnungen bescheunigen, aber man wird nie einen Interpreter auch 
nur um eine Größenordnung schneller machen.
Aber: Man kann es versuchen - und ich werde jeden unterstützen, der es 
versucht.

Beste Grüße

Volker

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-07 00:24 +0200

csiph-web