Walrus-Operator

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
Benutzeravatar
snafu
User
Beiträge: 6331
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 19. November 2020, 04:43

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?
Benutzeravatar
pillmuncher
User
Beiträge: 1266
Registriert: Samstag 21. März 2009, 22:59
Wohnort: München

Donnerstag 19. November 2020, 06:40

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.
In specifications, Murphy's Law supersedes Ohm's.
Benutzeravatar
snafu
User
Beiträge: 6331
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 19. November 2020, 08:10

Hab gehört, nächste Woche kommt das goto-Statement... ;)
Sirius3
User
Beiträge: 14594
Registriert: Sonntag 21. Oktober 2012, 17:20

Donnerstag 19. November 2020, 08:26

Gibt es doch schon: http://entrian.com/goto/
Benutzeravatar
snafu
User
Beiträge: 6331
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 19. November 2020, 09:27

Sirius3 hat geschrieben:
Donnerstag 19. November 2020, 08:26
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__
User
Beiträge: 9872
Registriert: Mittwoch 14. Oktober 2015, 14:29

Donnerstag 19. November 2020, 09:39

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 ==.
Benutzeravatar
sparrow
User
Beiträge: 2709
Registriert: Freitag 17. April 2009, 10:28

Donnerstag 19. November 2020, 09:52

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__
User
Beiträge: 9872
Registriert: Mittwoch 14. Oktober 2015, 14:29

Donnerstag 19. November 2020, 09:57

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.
Benutzeravatar
sparrow
User
Beiträge: 2709
Registriert: Freitag 17. April 2009, 10:28

Donnerstag 19. November 2020, 10:17

Ja, so sehe ich das auch. Keyword-only halte ich für sehr sinnvoll. Aber Keywords explizit abzuschalten - puuuh
Sirius3
User
Beiträge: 14594
Registriert: Sonntag 21. Oktober 2012, 17:20

Donnerstag 19. November 2020, 10:31

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.
Benutzeravatar
DeaD_EyE
User
Beiträge: 617
Registriert: Sonntag 19. September 2010, 13:45
Wohnort: Hagen
Kontaktdaten:

Donnerstag 19. November 2020, 13:26

snafu hat geschrieben:
Donnerstag 19. November 2020, 04:43
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.
sourceserver.info - sourceserver.info/wiki/ - ausgestorbener Support für HL2-Server
Benutzeravatar
__blackjack__
User
Beiträge: 8716
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Donnerstag 19. November 2020, 15:49

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.
long long ago; /* in a galaxy far far away */
Benutzeravatar
sls
User
Beiträge: 461
Registriert: Mittwoch 13. Mai 2015, 23:52
Wohnort: Country country = new Zealand();

Donnerstag 19. November 2020, 17:12

@__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.
When we say computer, we mean the electronic computer.
Benutzeravatar
snafu
User
Beiträge: 6331
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 19. November 2020, 17:21

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
User
Beiträge: 1306
Registriert: Samstag 16. April 2011, 12:47

Donnerstag 19. November 2020, 18:36

__blackjack__ hat geschrieben:
Donnerstag 19. November 2020, 15:49
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.
Antworten