Dieser Artikel war am 16. Oktober 2020 der Artikel des Tages.

Archiv

/Archiv/1 · /Archiv/2

Wie wird ein Archiv angelegt?

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 1080 Tage zurückliegt und die mindestens einen signierten Beitrag enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 2 Abschnitte.

Auf dieser Seite werden Abschnitte monatlich automatisch archiviert, deren jüngster Beitrag mehr als 180 Tage zurückliegt und die mindestens 2 signierte Beiträge enthalten. Um die Diskussionsseite nicht komplett zu leeren, verbleiben mindestens 5 Abschnitte.

Warum wurde die Änderung rückgängig gemacht, die neben Java auch .NET nennt, wenn es darum geht, dass Zeichenketten unveränderlich gespeichert werden? Die Änderung war korrekt und sachlich richtig. Hast du eine persönliche Präferenz? --My2Cents (Diskussion) 14:30, 30. Jun. 2020 (CEST)Beantworten

Aktuelle Python-Versionen ab 3.5 unterstützen die optionale Annotation von Objekten mit Datentypen. Daher wird in der Infobox vom englischen Artikel auch von "gradual Typing" gesprochen, mit PEP 483 als Referenz. Und die Unterstützung davon wird in der Zukunft vermutlich nur wachsen. Mit der Bibliothek MyPy kann man seine Programme auch einer statischen Typprüfung unterziehen. Daher ist Aussage aus dem Artikel

eine statische Typprüfung wie z. B. bei C++ gibt es nicht

zu stark. Die Aussage ist auch nicht ganz falsch, per Voreinstellung ist keine statische Typprüfung eingebaut, außer man verwendet zusätzliche Bibliotheken, und sie ist ganz sicher nicht wie bei C++. Aber die Sprache selbst unterstützt die Bibliotheken zur statischen Prüfung bewusst. Daher würde ich diese Aussage relativieren und die optionalen Typ-Annotationen im Artikel erwähnen. --Elimik31 (Diskussion) 12:50, 16. Okt. 2020 (CEST)Beantworten

Der Python Interpreter führt keine Typprüfung durch. Daher halte ich die Aussage für korrekt. Type Hints allerdings sind ein Feature welches zunehmend Unterstützung erfährt. Allerdings ist diese Typprüfung nur für Type Checker im Rahmen des Developments gedacht. Während der Laufzeit gibt es, wie bereits erwähnt keine statische Typprüfung. --2001:9E8:6C65:B400:177B:F79D:C488:2501 19:11, 8. Mär. 2022 (CET)Beantworten

Mittlerweile scheint es auch Taschenrechner mit einer Implementation zu geben. Casio (FX-9860 GⅢ, https://edu.casio.com/products/graphic/fx9860g3/) und ti (84 Plus CE-T, 83 Premium CE Edition) stand auf den Geräten, die mir unterkamen und hierhin zu gehören scheinen — wobei Casio ja längst auch auf Geräten zu finden ist, auf denen sonst hp steht (z. B. hp 300S Plus vs. Casio 991 o. ä.). (nicht signierter Beitrag von 93.229.106.129 (Diskussion) 00:19, 8. Nov. 2020 (CET))Beantworten

Die Aussage Auf diese Weise erhält man die drei Funktionsobjekte pop, push, is_empty, um den Stack zu modifizieren bzw. auf enthaltene Elemente zu prüfen, ohne l direkt modifizieren zu können. ist schlichtweg falsch. Es bedarf nur einer Python Installation um dies selbst zu verifizieren. [1]

push('Hello world')
l = pop.__closure__[1].cell_contents
print(l)
l.append(42)
print(pop())

Warum meine Änderung unter Verweis auf die Belegpflicht entfernt wurde, obgleich o.g. Falschaussage genau so wenig belegt ist, erschließt sich mir nicht. Wissenschaftliche Artikel zu diesem speziellen Feature der Programmiersprache Python sind mir nicht geläufig. --2001:16B8:6463:B600:7A1A:C2A0:31DF:FE56 00:58, 28. Feb. 2022 (CET)Beantworten

Das geht schlicht und ergreifend am Thema vorbei. Python ist eine introspektive Sprache, daher kann man immer auf (fast) alle Objekte direkt zugreifen und Kapselungen umgehen; dies liegt in der Natur der Sprache. Kapselung wird nicht erzwungen (mit einer Ausnahme, aber das würde hier zu weit führen); das gilt z.B. auch für Klassen- und Instanz-Attribute, für Properties und vieles mehr. Dies wird bereits an anderer Stelle im Artikel erwähnt. Das einzige, das an dem ursprünglichen Satz verbessert werden könnte, ist das Wort „können“ durch „müssen“ zu ersetzen. --Winof (Diskussion) 16:54, 2. Mär. 2022 (CET)Beantworten

Könnte man den Satz nicht einfach streichen, da er nachweislich (s.o.) sachlich falsch ist? --2001:9E8:6C65:B400:7627:EAFF:FEA9:DF7D 18:41, 8. Mär. 2022 (CET)Beantworten

PS: Der geänderte Text ist sachlich nicht mehr falsch. Allerdings fehlt zu der Aussage ein Beleg. Wie belegt man die Aussage

Auf diese Weise erhält man die drei Funktionsobjekte pop, push, is_empty, um den Stack zu modifizieren bzw. auf enthaltene Elemente zu prüfen, ohne dabei auf l direkt zuzugreifen.

am besten? --2001:9E8:6C65:B400:177B:F79D:C488:2501 18:52, 8. Mär. 2022 (CET)Beantworten

Meiner Meinung nach könnte der Abschnitt zur funktionalen Programmierung einen Hinweis auf functools vertragen. Hingegen verstehe ich nicht, warum als erstes auf Coconut hingewiesen wird, da es eine komplett andere Programmiersprache ist. (nicht signierter Beitrag von 2001:9E8:6C65:B400:177B:F79D:C488:2501 (Diskussion) 19:03, 8. Mär. 2022 (CET))Beantworten

Anders als im Artikeltext beschrieben, gibt es in Python ein Semi-Äquivalent von switch. Dieses heißt jedoch match und funktioniert etwas anders. --FF-11(Disk.|Bewertung|Beiträge)•Jungwikipedianer 18:27, 22. Jun. 2022 (CEST)Beantworten

Nun ja, man muss das etwas differenziert betrachten; „etwas anders“ ist eine Untertreibung. Konstrukte wie switch in C/C++ oder case in der Bourne-Shell sind im Grunde genommen nichts weiter als ein Ersatz für if…else-Kaskaden, d.h. if-Abfragen mit mehreren Alternativen (Mehrfachverzweigung). Dagegen dient das match…case-Konstrukt, das kürzlich mit Python 3.10 eingeführt wurde, für „structured pattern matching“ (ich bin nicht sicher, ob es einen etablierten deutschen Fachbegriff dafür gibt), wie es vor allem in funktionalen Sprachen verbreitet ist, z. B. Haskell, Erlang und Scala, wobei das Binden von Werten aus dem Pattern auf lokale Variablen ein zentraler Aspekt ist. Man kann dies auch für einfache (aber nicht alle!) Anwendungsfälle von if…else-Kaskaden „missbrauchen“, aber es gibt da ein paar Stolpersteine. Der folgende Schnipsel hat z B. nicht das Ergebnis, das man vielleicht erwarten würde:

RED = 1
GREEN = 2
BLUE = 3

...

switch mycolor:
    match RED:
        print ("Farbe ist rot")
    ...

Dieser Code ist fehlerhaft (also bitte nicht als Beispiel verwenden!) und gibt immer den Text „Farbe ist rot“ aus, egal welchen Wert die Variable mycolor hat, weil das Pattern-Matching eben anders funktioniert als ein if-Ausdruck. Aus diesem Grund ist die Aussage durchaus weiterhin korrekt, dass Python kein gleichwertiges Äquivalent von switch (C/C++), case (Shell) o. ä. hat. Nichtsdestotrotz ist das neue Pattern-Matching in Python ein extrem mächtiges Werkzeug, das in dem Artikel einen eigenen Abschnitt verdient hat. Wer neugierig ist, dem empfehle ich die Lektüre des Tutorials in PEP 636. --Winof (Diskussion) 12:43, 23. Jun. 2022 (CEST)Beantworten