Walrus-Operator

[snafu]

Wie findet ihr den seit Python 3.8 eingeführten Walrus-Operator? Ich bin da etwas zwiespältig eingestellt. Zuvor war ich zwar auch skeptisch gegenüber f-Strings, empfinde sie nun aber als eine große Bereicherung. Fraglich ist allerdings, ob das in diesem Fall auch passieren wird. Der Walrus-Ansatz ist sicherlich gut gemeint, verleitet aber auch schnell zu schwer lesbarem Code. Viele kennen das bestimmt von C, wo "Assignment Expressions" zwar möglich sind, jedoch nicht immer so gern gesehen werden. Tut sich Python wirklich einen Gefallen damit, dass man jetzt so etwas ähnliches eingeführt hat?

[pillmuncher]

Die Frage ist, welches Problem damit gelöst werden soll. Mir scheint, das Problem war, dass Python nicht genug wie C war, oder so. Die ganze Programmier-Welt wird immer funktionaler, und dagegen musste man scheinbar angehen. Wahrscheinlich führt man als nächstes peek und poke ein. Oder jemandem fällt ein, dass Python Duff's Device braucht.

[snafu]

Hab gehört, nächste Woche kommt das goto-Statement...

[Sirius3]

Gibt es doch schon: http://entrian.com/goto/

[snafu]

Gibt es doch schon: http://entrian.com/goto/

Schon bekannt.

Aber die Beispiele sind dennoch der Knaller:

Code: Alles auswählen

# Example 2: Restarting a loop:
from goto import goto, label
label .start
for i in range(1, 4):
    print i
    if i == 2:
        try:
            output = message
        except NameError:
            print "Oops - forgot to define 'message'!  Start again."
            message = "Hello world"
            goto .start
print output, "\n"

[__deets__]

Ist kein Durchbruch für mich, aber gewisse Muster wie eben die in den Beispielen angeführten regulären Ausdrücke sind schon etwas öde in python. Die Kritik, dass es dabei wie in C zu Fehlern kommen würde, teile ich nicht. IMHO ist := und == zu unterscheiden auch bei oberflächlichem lesen gut möglich. Besser als = und ==.

[sparrow]

Mich triggert der Operator, weil er mich an alte Pascal-Zeiten erinnert - also rein optisch.

Die Benutzung leuchtet mir aber deutlich mehr ein als die Einführung von "Positional-only parameters" und "Keyword-only parameters".

[__deets__]

Keyword only finde ich super! Das gibts ja schon länger. Erzwingt mehr Klarheit IMHO auf der Aufruferseite. Und beugt Fehlern vor.

Die erzwungenen Positionals sind mir unklar. Ich meine mal gehört zu haben, dass es da mehr um FFI wie ctypes geht - wenn man da zb Python und C Funktionen mischt, etwa bei callbacks, kann man so dagegen vorbeugen, dass eine zu C inkompatible aufrufart gewählt wird. Mag aber auch falsch sein als Erinnerungsfetzen.

[sparrow]

Ja, so sehe ich das auch. Keyword-only halte ich für sehr sinnvoll. Aber Keywords explizit abzuschalten - puuuh

[Sirius3]

Mich stört umgekehrt, dass viele Builtin-Funktionen keine Keyword-Argumente erlauben.

Code: Alles auswählen

pow3 = functools.partial(pow, y=3)
print(pow3(5))
# TypeError: pow() takes no keyword arguments

Das war früher halt einfach so, weil sich bei der ersten Implementierung wahrscheinlich niemand Gedanken darüber gemacht hatte, mit positional-only parameters wurde das jetzt aber festzementiert.

[DeaD_EyE]

Tut sich Python wirklich einen Gefallen damit, dass man jetzt so etwas ähnliches eingeführt hat?

Ich mag den Walrus-Operator und eingesetzt habe ich ihn auch schon öfters.
Für Anfänger ist es ein Problem, da die Sprache Python immer umfangreicher wird.


Ich wende seit über 10 Jahren Python an und seit Python 3.5 nutzte ich kein Python 2.7 mehr.
Die Entwicklung von Python 3000 habe ich miterlebt und es hat sich enorm viel geändert.
Wenn man nur zwischen den Veröffentlichungen vergleicht, halten sich die Änderungen in Grenzen.
Vergleicht man Python 3.4 z.B. mit Python 3.9, sind die Änderung massiv.

Man könnte glatt mehrere Seiten voll schreiben, mit dem was sich alles geändert hat. In der Library und in der Sprache.

[__blackjack__]

Ich denke Python hat den Zenit überschritten. Die Sprache war ”perfekt” und jetzt werden einfach nur noch zusätzliche Features reingestopft und es wird immer komplexer. Bin gespannt mit welcher Bedeutung die ``!``- und ``$``-Operatoren irgendwann mal belegt werden, nachden auch ``@`` ein Operator geworden ist.

Jetzt wurde der Parser schon komplexer gemacht um auch vorläufig mehrdeutigen Code parsen zu können für das kommende „pattern matching“ was die Sprache auch wieder komplexer machen wird. Es wird drauf getackert was gerade in anderen Sprachen populär ist.

Irgendwann wird dann die nächste Sprache kommen die einfach anfängt und die sich dann alle stürzen weil sie den Punkt zwischen einfach und anfängertauglich und praktisch einsetzbar besser trifft.

[sls]

@__blackjack__: ich sehe das ganz ähnlich. Was mich besonders nervt sind Typ-Annotationen da sie den sonst schlanken und leicht lesbaren Python-Code aufblähen oder die IDE teilweise mit diesen nicht klarkommt und motzt.

Der Walrus-Operator ist da für mich auch so ein zusätzliches Feature das in seltenen Fällen "nice-to-have" ist, aber die Sprache damit ohne imho auch ganz gut auskam. Ich finde auch die Verwirrungen um Positional-Only, Positional-or-Keyword-Arguments und was es da nicht sonst alles gibt insgesamt schädlicher als nützlich.

Mir persönlich wäre es lieber man würde die Energie um solche Sprach-Features in ein einfacheres Packaging bzw. Setup-Prozess investieren (evtl. wie Rust o. Go das löst?). Das wurde schon letztes Jahr von Core-Developern auf der Pycon in Berlin kritisiert und Python lebt aktuell ja vom Boost durch das ganze fancy ML / AI / BigData-Zeug.

[snafu]

Zumal ja nun jährliche Versionssprünge kommen sollen...

Naja, ich habe den Walrus-Operator auch schon eingesetzt, aber man kann IMHO einfach zuviel Mist damit anstellen. Ich verfolge ja so ein bisschen die Commits auf der Github-Seite von CPython und inzwischen ist der wohl auch für List/Set/Whatever Comprehensions und selbst bei einem Indexzugriff implementiert. Das finden manche Leute bestimmt sinnvoll, aber ich kann damit wenig anfangen. Beim Beispiel mit der Schnittstelle des re-Moduls und auch in ein paar anderen Fällen spart man tatsächlich etwas Code, aber darauf hätte man es beschränken sollen, finde ich. Halt in dem Sinne, dass man ihn nur für Schleifen und Bedingungen erlaubt, nicht aber in verschachtelten Ausdrücken.

[nezzcarth]

Die Sprache war ”perfekt” und jetzt werden einfach nur noch zusätzliche Features reingestopft und es wird immer komplexer.

Dieses Thema hatte ich letztens auch im privaten Umfeld. Mein Eindruck ist, dass es Sprachentwicklern generell erstaunlich schwier zu fallen scheint, die Füße still zu halten, eine Sprache (also deren Syntax/formale Definition) einfach mal als "abgeschlosses Gesamtkunstwerk" anzusehen und nicht permanent daran irgendwelche Ergänzungen vorzunehmen. Mir fallen jedenfalls kaum Beispiele ein, in denen die Sprache nicht spätestens alle paar Jahre eine neue Version, einen neuen Standard etc. bekommt, der irgendwelche Features nachrüstet. Es scheint da einen unterschwelligen (vermeintlichen) Innovationsdruck zu geben, dem die meisten erliegen. Dafür gibt es sicher diverse Motivationen/Gründe. Sicher spielt da auch mit rein, dass ausbleibende Änderungen dafür sorgen könnten, dass die Sprache als "tot" gilt.

[noisefloor]

Hallo,

Mein Eindruck ist, dass es Sprachentwicklern generell erstaunlich schwer zu fallen scheint, die Füße still zu halten, eine Sprache (also deren Syntax/formale Definition) einfach mal als "abgeschlosses Gesamtkunstwerk" anzusehen und nicht permanent daran irgendwelche Ergänzungen vorzunehmen.

Kommt drauf an. Was mir als Gegenbeispiel einfällt ist Lua. Das ist ja schon irgendwie im Mainstream, wenn auch weit von der Popularität von Python & Co entfernt. Bei Lua braucht man seit Version 5 so 3-5 Jahre für den nächsten Minor-Release.

Bei Python denke ich auch, dass da ein gewisser "Erfolgsdruck bedingt durch die Popularität" herrscht. Andererseits lesen sich IMHO die PEPs, die umgesetzt werden, in den allermeisten Fällen plausibel. Auch, wenn ich selber viele Sachen selber nicht einsetze bzw. vermisst habe (wie Type Annotations).

Solange Python nicht auf ein so komisches Release-Modell wie Java wechselt, wo die Short-Term-Support Versionen nur 9 Monate Support haben...

Gruß, noisefloor

[__blackjack__]

@noisefloor: Bei Lua werden die Sprachentwickler von der Community extrem ausgebremst. Die würden gerne mehr machen, aber die Leute benutzen einfach nur die Uralt-Versionen. So ein bisschen wie bei Python 2.7 nur das ich bei Lua nicht sehe das sich die Sprachentwickler da durchsetzen könnten.

Typannotationen sind der erste Fall den ich so richtig krass fand. Traditionell hat Guido ja immer nur Sachen ”genehmigt”, die einen klaren Nutzen/Vorteil haben. Und dann kam er plötzlich mit Syntax für Annotationen um die Ecke. Wofür? Für *irgendwas*! Macht damit was ihr wollt. Mal schauen was da interessantes bei herum kommt. Es hat kaum jemand benutzt. Unter anderem auch weil es ja nicht unproblematisch ist wenn Bibliothek A die Annotationen für irgendwas benutzt und Bibliothek B die Annotationen für irgendetwas anderes benutzt. Und nach dem laaaange Zeit nur ganz wenige Bibliotheken mit den Annotationen experimentiert haben, hat Guido entschieden, dass die ab sofort für Typannotationen verwendet werden. Und zwar nur dafür. Und irgendwie auch weil das gerade ”in” ist. Also im Grunde Typescript & Co nachgeäfft. Und vielleicht weil Python in Unis mehr verwendet wird und die Profs auf statische Typorgien stehen um da noch mehr Fuss zu fassen.

Der Walruss-Operator war letztlich ja auch der Grund aus dem Guido den Posten als BDFL niedergelegt hat, weil da echt heftiger Unmut aus der (auch engeren) Community kam.

[nezzcarth]

Kommt drauf an. Was mir als Gegenbeispiel einfällt ist Lua. Das ist ja schon irgendwie im Mainstream, wenn auch weit von der Popularität von Python & Co entfernt. Bei Lua braucht man seit Version 5 so 3-5 Jahre für den nächsten Minor-Release.

Danke für das Beispiel Ich kann mir vorstellen, dass das bei einer Sprache, die vor allem eingebettet wird, auch noch mal etwas anders ist. Wenn man lua in irgendein Spiel oder eine Anwendung einbaut, möchte man vielleicht keine Änderung an der Sprache haben, die dafür sorgen, dass Plugins/Mods auf einmal nicht mehr funktionieren oder Inkompatibilität zwischen Versionen erzeugen.

[pillmuncher]

@__blackjack__: Type Annotations könnte man für Property Based Testing verwenden. Hypothesis macht das anscheinend, aber ich hab es mir nicht genauer angeschaut.

[noisefloor]

Hallo,

bzgl. Type Hints: ich habe vor ein oder zwei Jahren mal ein Video von ein er Pycon gesehen, wie jemand von Instagram erzählt, wie sie Type Hints und Type Checking (ich meine mit mypy) eingeführt haben und was es für die gebracht hat bzw. immer noch bringt. Vom Use Case her war das in dem Fall sehr plausibel und einleuchtend. Ich selber habe das aber nie vermisst und sehe auch keinen Grund, warum nicht das nutzen sollten.
Keine Ahnung, ob Type Checking ab einer bestimmten Größe und Komplexität von Programm (wie Instagram) sinnvoll ist und das Feature in erster Linie für die "entreprise level" Nutzer von Interesse ist.

Gruß, noisefloor