Diskussion:Python (Programmiersprache)

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

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Python (Programmiersprache)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Archiv

/Archiv/1 · /Archiv/2

Wie wird ein Archiv angelegt?

Automatische Archivierung

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.

Automatische Archivierung

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.

Kritikabschnitt

Mal davon ab, dass nicht viele Sprachen einen haben (Perl, erwartbar), von wann ist der eigentlich? Die Quellen führen in's Webarchiv oder auf Zeitungsartikel von sage und schreibe 1999! Los geht's mit einer bloßen Empfindung, deren Anstoß ich nur von hier kenne. Folgt eine Anekdote aus 2.x-Zeiten, die man sich in Kürze eh sparen möchte. Und dann natürlich der GIL: afaik auch so'n Dauerbrenner der 2000er Jahre, seit wann gibt's Multiprocessing in der Standardbibliothek jetzt? Glaube solange ich Python kenne und das ist auch schon ne Weile. Ausführungsgeschwindigkeit: um 2020? Das ist doch peinlich. Wenn man so einen Abschnitt will, dann muss er seinem Ansinnen gerecht werden und dann müsste man das auch mal pflegen. Oder irgendwann eben mal Konsequenzen ziehen und sowas auch einfach löschen, viell. hat mal wieder jemand Lust? Ich könnt bis dahin gut drauf verzichten und ziemlich das Einzige, was mir dazu einfiele, sich auf die Sprache i.e.S. bezieht, aber wohl auch schwerlich zitieren ließe, wären die mittlerweile vier, bzw. fünf Möglichkeiten formatierter Textausgabe, von wegen "one way to do it" - das ein und im Ggs. zu ich glaube allen jetzigen Punkten wenigstens auch recht einmaliges Merkmal von Python, aber sicher kaum weniger affig als das, was da jetzt steht. -ZT (Diskussion) 06:50, 14. Okt. 2019 (CEST)

Zustimmung in der Sache. Ich bin kein Experte, nur Freizeit-Programmierer (freilich mit gewissen grundsätzlichen Informatik-Kenntnissen), glaube aber auch feststellen zu können, dass der Abschnitt zumindest stark veraltet ist. „Mangelnde Typsicherheit“ z.B. lässt sich durch Einsatz von type annotations und mypy doch beheben. Auch bei dem (allerdings ubiquitären) Vorwurf mangelnder Ausführungsgeschwindigkeit sollte man zumindest klarmachen, (a) dass das in der Praxis bei vielen Programmen gar keine Rolle (mehr) spielt und (b) das die Ausführungsgeschwindigkeit stark von der eingesetzten Implementierung abhängt. Könnte ein wirklicher Kenner der Materie den Abschnitt grundlegend überarbeiten und aktualisieren? Das wäre super! --Aristeas (Diskussion) 17:34, 17. Nov. 2019 (CET)

Die Ausführungsgeschwindigkeit finde ich schon relevant. Python ist in dieser Disziplin auch unter Skriptsprachen nicht besonders optimiert. Dass die Geschwindigkeit für sehr viele Szenarien keine Rolle spielt ist richtig, aber dass man zur Zeit kaum eine langsamere Sprache findet, ist auch erwähnenswert. Natürlich sind Benchmarks nicht immer ganz aussagekräftig. --Diaspomod (Diskussion) 11:30, 18. Nov. 2019 (CET)

Was soll außerdem folgende Behauptung:

"Ferner wird die mangelnde statische Typsicherheit der Programmiersprache kritisiert.[49]"

In der Quelle [49] lese ich hingegen:

Der Mangel an statischer Typsicherheit impliziert auch Risiken, denen jedoch die Vorzüge einer dynamischen Sprache gegenüberstehen. Im Übrigen nötigen die meisten objektorientierten Sprachen, die angeblich ein statisches Typkonzept haben, de facto dauernd dazu, es mittels unsicherer Typumwandlung zu durchbrechen (das gilt auch für Java, siehe [2]), ohne jedoch die schönen Seiten eines dynamischen Konzepts zu bieten.

Klingt für mich nicht so, als sei die Quelle neutral und wertfrei wiedergegeben worden. "birgt Risiken" ist keine Kritik, und wenn danach ein Absatz folgt der die Vorzüge anpreist erst recht nicht. Sieht das jemand anders? Ansonsten würde ich das anders formulieren, näher an der Bewertung aus der Quelle. --TheRandomIP (Diskussion) 17:09, 1. Sep. 2020 (CEST)

Zu der Quelle: Dass Typumwandlung unsicher sein soll, ist so nicht richtig. Die Quelle spricht da vermutlich aus Javaperspektive, wo Downcasts eine Ausnahme werfen können, wenn man davor nicht mit dem "instanceof" Operator den Typ geprüft hat. Andere Sprachen wie C# und Kotlin geben da null zurück und erzwingen zum Teil typsichere Typumwandlungen per Design.

Die Aussage, dass man de facto andauernd dazu genötigt sei, Downcasts zu machen, ist nicht unbedingt realitätsgetreu und sachlich. --Diaspomod (Diskussion) 21:26, 1. Sep. 2020 (CEST)

Gibt es dann vielleicht andere Quellen, die die mangelnde statische Typsicherheit explizit kritisieren? --TheRandomIP (Diskussion) 22:06, 1. Sep. 2020 (CEST)

...scheinbar nicht, also habe ich den Satz entfernt. (Ein Umformulieren war nicht nötig, denn die Information, dass Python dynamische Typisierung verwendet, wurde schon an anderer Stelle im Artikel besprochen) --TheRandomIP (Diskussion) 14:35, 4. Sep. 2020 (CEST)

wikidata

Es geht um folgende Zurücksetzung von @Xqt:: https://de.wikipedia.org/w/index.php?title=Python_(Programmiersprache)&oldid=prev&diff=200334618&diffmode=source also darum, dass in der Infobox Erscheinungsdatum, Designer, Entwickler, Aktuelle Version, Aktuelle Version Freigabedatum, Beeinflusst Von, Lizenz und Website nicht aus wikidata kommen sollten, da "Wikidata ist fehlerhaft, siehe auch diesbezügliches MB". Zu den einzelnen Punkten:

• Erscheinungsdatum ist in wikidata korrekter, da mit Tag, Monat und Beleg
• Designer ist in wikidata ident zum Artikel inkl. Beleg
• Entwickler ist in wikidata korrekter, da Guido van Rossum inkl. Beleg auch erwähnt wird, ident zum Artikel, der ihn unter "Entwicklungsgeschichte" als Entwickler nennt
• Aktuelle Version war in wikidata nicht korrekt (2er Releasezweig hatte preferred rank) - wurde geändert und ist somit jetzt ident
• Aktuelle Version Freigabedatum - siehe oben
• Beeinflusst Von ist in wikidata korrekter, da belegt
• Lizenz und Website ist ident

d.h. Wikidata scheint weniger fehlerhaft zu sein als Wikipedia - außerdem können dort auch von jedermann Fehler behoben werden (d.h. man muss Fehler nicht in der Wikipedia ausbessern)

Mit Meinungsbild war vermutlich dieses gemeint: https://de.wikipedia.org/wiki/Wikipedia:Meinungsbilder/Nutzung_von_Daten_aus_Wikidata_im_ANR aus 2015 Der hier betroffene Punkt "Das Entfernen von Daten aus der deWP ... ist bis auf Weiteres unzulässig." wurde damals abgelehnt.

Fazit: Die Änderungen an der Infobox damit wikidate Infos dargestellt werden war sowohl inhaltlich sinnvoll (da der Artikel dadurch belegter und korrekter wird), als auch dem Meinungsbild entsprechend. --Sebastian.Dietrich ✉ 00:43, 27. Mai 2020 (CEST)

Also korrekt war da gar nichts: Über die Wikidata-Einbindung wurde nämlich das 2.7.18er-Release eingeblendet. Das ist lediglich ein 20. April veröffentlichter Hotfix einer Entwicklungslinie, die seit dem 1. Januar eingestellt ist. Die aktuelle Version ist 3.8.2. Mir ist nicht transparent, welche der in WD gesammelten Versionen-Eigenschaften hier eingeblendet wird, 2.7 ist jdenfalls die falsche. WD arbeitet seit Mitte Januar ohnehin nicht zuverlässig, zumindest aus API-Sicht; da gehen auch schon mal Daten verloren.  @xqt 08:00, 27. Mai 2020 (CEST)

Danke für diese Änderung. Aber wie kann dieser Unsinn verhindert werden, wo es haufenweise Einträge mit bevorzugtem Rang gibt?  @xqt 08:19, 27. Mai 2020 (CEST)

Ich bin kein Wikidata Spezialist - das mit dem Preferred Rank weiß ich selbst erst seit ein paar Monaten, weil die aktuelle Version bei einer Software partout nicht die letzte sein wollte. Ich vermute es sollte normalerweise so sein: keine Version bekommt einen preferred rank --> die letzte wird genommen. Den preferred Rank braucht man nur, wenn die (zeitlich) letzte Version nicht die letzte ist - das passiert aber nur wenn auch alte Versionen weiterentwickelt/gewartet werden. Das passiert zwar oft, aber in Wikidata kommen diese Versionen dann eh selten rein (niemand macht sich die Mühe Updates an alten Versionen zu aktualisieren). --Sebastian.Dietrich ✉ 20:11, 29. Mai 2020 (CEST)

.NET fehlt

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)

anspruch und wirklichkeit

"Sie hat den Anspruch, einen gut lesbaren, knappen Programmierstil zu fördern." python fördert nicht, python bestraft. ein falsches tab oder ein (wenn auch nur versehentlich) gelöschtes oder hinzugefügtes leerzeichen, und der scheiß fliegt dir um die ohren. was die formatierung angeht, ist python ca. 3mal so bösartig wie fortran. (nicht signierter Beitrag von 188.98.209.101 (Diskussion) 00:53, 16. Okt. 2020 (CEST))

Unter anderem ist Python auch case-sensitive, was dir sicher auch Probleme bereiten dürfte. Und die Schreibweise „3mal“ zeigt, dass du auch außerhalb von Python Schwierigkeiten mit Leerzeichen hast …
Wie auch immer: Die Artikeldiskussion dient der Verbesserung des Artikels, nicht der Darstellung der eigenen Meinung zum Thema. Wenn du enzyklopädietaugliche Quellen beibringst, die diesen von dir zitierten Anspruch von Python als nicht eingelöst beschreiben, kann das natürlich ebenfalls in den Artikel.
Troubled @sset   ^{[ Talk ]}   07:02, 16. Okt. 2020 (CEST)

Wie bei allem der Unterschied zwischen Theorie und Praxis. Enzyklopädietaugliche Quellen wollen doch Python promoten. Keiner schreibt ein Fachbuch «Warum Python Scheisse ist». Er disqualifiziert sich dann selber in der Community. Das Python wie viele andere Programmiersprachen schlicht nicht berücksichtigt ist, das Menschen Programme schreiben, und die vertippen sich ist nun mal eine Tatsache. Das Menschen Variablen verwechseln auch. Ein System welches nicht so viel wie möglich Fehler bei der Auslieferung erkennt ist einfach Schrott «Python is a dynamically typed language. This means that the Python interpreter does type checking only as code runs, and that the type of a variable is allowed to change over its lifetime.[[1]] «Static type checks are performed without running the program. In most statically typed languages, for instance C and Java, this is done as your program is compiled.». Man braucht jetzt wirklich kein Experte zu sein um Folgendes festzustellen: Man schreibt an einem grossen Programm. Es verarbeitet Datensätze zu Rechnungen. In einer Funktion verwechsele man Variable i mit I. Der Fehler wird nicht sofort erkannt. Nein, er wird Wochen später erkannt, nachdem Hunderte fehlerhafter Rechnungen an Kunden verschickt wurden. Aber so etwas steht nicht in Enzyklopädietaugliche Quellen. Keiner gibt sich die Blösse das er ein Looser ist der i mit I verwechselt. Wie bei allen Skriptsprachen sollte eine Warnung in den Artikel. «Bitte beachten: Python schadet ihrer Gesundheit. Es wird sie in den Wahnsinn bei grösseren Projekten treiben!» Python ist nicht Typ Sicher und deswegen abzulehnen. Der Testaufwand in grösseren Projekten ist einfach zu gross! Guten Morgen. ไม่เป็นไร (Valanagut) (Diskussion) 09:29, 16. Okt. 2020 (CEST)

Keiner schreibt ein Fachbuch «Warum Python Scheisse ist».

Polemisch. Schon mal "Why x is bad" in eine Suchmaschine eingegeben? 185.69.244.136 13:56, 16. Okt. 2020 (CEST) --

ich möchte noch anmerken, daß der von mir zitierte satz zunächst mal marketinggeschwafel ist. was die entwickler sich gewünscht haben, ist irrelevant. ich sehe auch deswegen keinen grund, warum ich (oder irgendjemand anderes) die beweislast tragen soll, das zu widerlegen. wer eine behauptung aufstellt, soll sie auch beweisen. (nicht signierter Beitrag von 188.98.217.58 (Diskussion) 15:53, 16. Okt. 2020 (CEST))

Im Artikel steht, dass Python diesen Anspruch erhebt, nicht, dass es ihn zu 100 Prozent einlöst. Der Satz wäre dann und nur dann falsch, wenn Python diesen Anspruch gar nicht erheben würde. Ist das so?
Im Übrigen frage ich mich schon, warum Python auch im profesisonellen Umfeld für bestimmte Einsatzzwecke diese Verbreitung gefunden hat, wenn die Sprache dermaßenh unbrauchbar ist. Entwickler, die eine strenge Typisierung haben wollen, müssen dann eben eine andere Sprache verwenden.
Wenn ich im C/C++/C#-Bereich sehe, wie Klassen und Methoden mit ansonsten identischen Bezeichungen mal im MixedCase und mal im camelCase benannt (und dann womöglich noch inkonsistent überladen) werden und die Entwickler das schon mal durcheinanderbringen, ohne dass der Compiler eine Warnung ausgibt, stellt man fest, dass Warnungen auch nicht vor allen solchen Fehlern schützen. Wenn man in Projekten, in denen nicht auf eine strikte Typeinhaltung geachtet und viel mit impliziten Typ-Konversionen gearbeitet wird, dann die entsprechenden Compilerwarnungen aktiviert und plötzlich 5000 Warnings bekommt, kann man auch nicht sicher sein, ob die alle harmlos sind. Man muss die Sprachen einfach sinnvoll einsetzen. Gerade bei Python ist eine strikte Namenskonvention sinnvoll, dadurch werden viele dieser Fehler schon im Ansatz vermieden. Meine Entwicklungsumgebung warnt mich im Übrigen, wenn ich eine noch nicht verwendete Variable, Methode etc. eintippe, und ich kann dann entscheiden, ob ich hier wirklich ein neues Element einfügen will oder mich nur vertippt habe. Man kann auch eine Liste aller definierten Variablen mitführen und schon während der Entwicklung nach jedem Testlauf automatisch prüfen lassen, ob alle während der Ausführung dynamisch angelegten Variablen etc. auch tatsächlich vorhanden sein sollen.
Das verwechselte i und I kommt gar nie in die Produktion, wenn man sich an die elementarsten Regeln für professionelle Software hält, weil das bereits während der Entwicklungsphase spätestens durch einen Unit Test aufgefallen wäre (auch in Python darf man Unit Tests und andere automatisierte Testkonzepte anwenden).
Wir sind hier aber auf der falschen Seite für solche Diskussionen. Troubled @sset   ^{[ Talk ]}   12:40, 18. Okt. 2020 (CEST)

Für die Interessierten: Python for C# Developers aus dem Code Magazine. (nicht signierter Beitrag von Troubled asset (Diskussion | Beiträge) 18:25, 18. Okt. 2020 (CEST))

Optionale statische (graduelle) Typprüfung ab Python 3.5

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)

Strukturierung durch Einrücken

Zitat: Für Programmierneulinge wird der Zwang zu lesbarem Stil aber als Vorteil gesehen. An dieser Stelle fehlen Belege, wer das als Vorteil sieht; auch der erwähnte Vorschlag von Peter J. Landin ist unbelegt (ist er auch in dessen biographischem Artikel).

Von fehlenden Belegen abgesehen, ist dieser Satz ein seltsam flüchtiges Argument. "Programmierneulinge" bleiben einerseits nicht lange Neulinge und andererseits haben die meisten Pythonnutzer bereits Erfahrung mit anderen Sprachen. Python beansprucht ja ausdrücklich nicht, eine "Lehr-" bzw. "Ausbildungssprache" zu sein (wie Pascal). Also obigen Satz bitte belegen oder streichen! Besser noch einen Beleg zur "off-side rule" von Landin (hier oder dort) einfügen. Ganz apart wäre natürlich eine Quelle, die Anspruch und tatsächliche Wirkung der "off-side rule" untersucht und bewertet. Gruß, --Burkhard (Diskussion) 14:46, 16. Okt. 2020 (CEST)

Glaube nicht, dass es so gemeint war, aber als jemand, der den Code von Programmierneulingen lesen muss, sehe ich es als Vorteil, wenn diese zu lesbarem Code gezwungen werden. Erfahrene Programmierer schreiben in den meisten Sprachen lesbar. Ob es für die Anfänger selbst hilfreich ist, ist diskussionsbedürftig. Aber, dass es ein Ziel der Sprache ist, lesbaren Code zu produzieren, steht ja schon oben im Artikel und sollte man hier nicht wiederholen. Übrigens, wie in jeder anderen Programmiersprache kann man auch in Python schwer lesbaren Code schreiben. Deswegen setzen viele Python-Projekte die Einhaltung von Stilvorgaben wie PEP8 vorraus. Dafür helfen Entwicklungsumbebungen, die Stilfehler automatisch markieren und auf Wunsch Code automatisch formattieren. Aber das selbe gilt auch für andere Programmiersprachen. Da läuft vielleicht nicht-indentierter Code theoretisch, aber die Indentantion von den Stilvorgaben gefordert und von der Entwicklungsumgebung meist automatisch eingefügt.

--Elimik31 (Diskussion) 18:18, 16. Okt. 2020 (CEST).

Was wie gemeint war, glaubst Du nicht??? Aussagen in Artikeln müssen belegt sein - das ist der Diskussionspunkt - nicht das Thema Lesbarkeit durch Einrücken an sich. Wenn obiges Statement konkreten Autoren zugeschrieben werden kann, dann her mit dem Beleg; wenn es Studien oder gar Sekundärliteratur zu dem Thema "Zwang zu lesbaren Code" gibt, erst recht. Drumrummogeln durch Passivstil gilt nicht. --Burkhard (Diskussion) 20:51, 16. Okt. 2020 (CEST)

Korrektes Einrücken kenne ich noch aus der Zeit, als ich in COBOL programmieren mußte. Ist glücklicherweise schon lange her.--Jost Riedel (Diskussion) 18:41, 16. Okt. 2020 (CEST)

ich kann nur jedem empfehlen, sich mal https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements zu gemüte zu führen. da wird im detail angegeben, wo man wieviele leerzeichen eingeben soll. also auch an stellen, die im ggs. zur einrückung keinerlei auswirkung auf die programmausführung haben. humbug, in meinen augen. da wird mit vermeintlich besserer "lesbarkeit" argumentiert, obwohl dem erfahrenen programmierer klar sein sollte, daß "lesbarkeit von code" erstens nicht objektiv ist (sofern es nur um leerzeichen etc geht) und zweitens von anderen, viel wichtigeren faktoren abhängt. z.b. davon, daß man variablen, klassen und funktionen möglichst verständlich benennt. i, j und k sind als schleifenzähler in ordnung, aber ansonsten sollte man eine variable besser "mainWindow" als nur "w" benennen. reguläre ausdrücke sind ein nützliches konstrukt, aber einer "re.match" anweisung sieht man oft nicht an, nach welcher art ausdruck damit gesucht werden soll. ein kommentar mit einem beispielstring, der die suchkriterien erfüllt, kann da hilfreich sein. grundsätzlich schlecht ist auch, daß python förmlich dazu einlädt, globale variablen und funktionen einfach da zu definieren, wo es gerade paßt. wenn man in einer funktion dann eine variable definiert, die denselben namen hat wie eine schon existierende globale, kein problem. nichtmal eine warnung. das ist schon sehr schlecht gelöst. (nicht signierter Beitrag von 188.98.217.58 (Diskussion) 23:21, 16. Okt. 2020 (CEST))

Die Aussage gilt, wenn auch nicht unbedingt objektiv, nur für das Einrücken. Das ist in meiner subjektiven Meinung neben anderen Faktoren schon eines der wichtigen Kriterien für die Lesbarkeit. Und Python erzwingt es eben als syntaktische Vorgabe. Bei sog. Neulingen, die davor nie programmiert haben und die Grundlagen erlernen, kann man das didaktisch positiv bewerten, da ein nicht eingerückter Code in Python niemals ausführbar ist und so keine Erfolgserlebnisse durch nicht formatierten Code entstehen. Man kann sicherlich eine Quelle dafür finden, die das bestätigt. Auch wenn es sich bei der Informatik um eine Naturwissenschaft handelt, gibt es da auch verschieden auswählbare Alternativen bei Problemlösungen, die man am Ende subjektiv aussucht. Man kann den Satz z.B. auch in eine abgeschwächte Formulierung überführen, die das subjektive Empfinden dabei klarstellt. --Diaspomod (Diskussion) 16:44, 17. Okt. 2020 (CEST)

Anonyme Namensräume?

"Anonyme Namensräume (sog. Closures) sind mit den o. g. Mechanismen in Python ebenfalls einfach möglich.". Anonyme Namensräume gibt es in C++, hier sind wohl eher anonyme Funktionen gemeint. Aber: Closures sind keinesfalls das Gleiche wie anonyme Funktionen. Zwar werden in vielen Sprachen Closures durch anonyme Funktionen realisiert, aber Closures können auch durch Funktionen mit Namen realisiert werden. Wie das Beispiel zeigt: Da gibt es nur Funktionen mit Namen.--Jost Riedel (Diskussion) 22:42, 16. Okt. 2020 (CEST)

Würde "Anonyme Namensräume (sog. Closures)" durch "Closures" ersetzen, da die Begriffe wie gesagt keine Synonyme sind und es sich hier um Closures handelt. --Diaspomod (Diskussion) 16:31, 17. Okt. 2020 (CEST)

Taschenrechner

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))