nullPtr schrieb:
Selbstverständlich ist das eine. Es muss eben nur dokumentiert sein, was der Rückgabewert bedeutet. Exceptions müssen ebenso dokumentiert sein.
Man kann sich sicherlich über die Terminologie streiten, wenn man argumentiert das sein Code von der Semantik her ähnliche Funktionalität bieten soll, wie wirkliche Fehlerbehandlung. Jener Umstand ändert aber nichts an der Tatsache, dass bei Python in den PEPs ausschließlich die vorgegebenen Exceptions plus custom Exceptions, die von der
Exception-Basisklasse (oder einer Subklasse) erben, für Fehlerbehandlung in Python genutzt werden sollen.
Auch bei beispielsweise Wikipedia findet man nur explizite Hinweise, dass diese zu verwenden sind und von anderen Sachen abzusehen ist.
Unabhängig davon würde ich bei seinem Beispiel auch bei der Terminologie den Terminus
Fehlerbehandlung kritisieren, da eine Fehlerbehandlung aus einer qualifizierten Angabe bzw. Standardisierung von Fehlertypen besteht. Jegliche Angabe, Beschreibung, Standardisierung oder Hierarchie fehlt in seinem Beispiel aber vollständig.
Natürlich hast du insofern Recht, als das dies als einfaches Beispiel für eine Custom-"Fehlerbehandlung" dienen kann. Seine Intention ist mir also durchaus klar. Nur ist es eben keine richtige, keine die man als "pythonic" bezeichnen würde und vor allem ist es "quick'n'dirty". Genau solcher schlechter Code - da kurz, knapp & simpel - ist es aber, der dann von Anfängern häufig für bare Münze genommen wird und kopiert/verwendet wird.
Schon hat man weitere Leute geschaffen, die schlechten Code verbreiten. Was als harmloses, einfaches, kurzes Beispiel begann, findet damit seinen Weg in herkömmliche Softwareentwicklung.
Blubmann schrieb:
Selbst jede höhere Sprache mit JIT (C#) optimiert das weg.
Bei Python - da interpretiert - kann dies nicht optimiert werden. Der Interpreter muss zur Laufzeit ja ermitteln, womit der Rückgabewert seiner Funktion verglichen werden soll. Unabhängig davon halte ich "der Compiler optimiert das weg" für keine Rechtfertigung schlechten Code zu schreiben. In Java oder C++ wäre das ebenso "bad style". Im Übrigen könnte das auch von einem Compiler nur dann optimiert werden, wenn zur Compilezeit feststünde, dass die condition immer zu einem boolean evaluiert - z.B. bei template metaprogramming in C++ könnte man da sicherlich cases erzeugen, wo der Compiler zur Compilezeit dies nicht mehr kann...aber selbst in einem gekünsteltem Trivialfall "if some-int == True" wäre es schon nicht mehr optimierbar und <stdbool.h> in C z.B. definiert True mit 1 (integer).
Viel wichtiger ist aber was dahintersteckt: Derartiges weißt i.d.R. auf mangelnde Programmierkenntnisse (besonders in puncto Theorie) hin.
Wer schon mal ein Buch über "bad habits" beim Programmieren gelesen hat, weiß das explizite Vergleiche mit Booleans dazu gehören und
ein Indikator für schlechten Code sind (wenn sicherlich aber auch kein besonders wichtiger).
Blubmann schrieb:
Des Weiteren sind solche expliziten Vergleiche durchaus sinnvoll, einmal um bei Pythons Ducktyping für den Leser den Typ klarzumachen (Ist es eine Ganzzahl? Oder ein Objekt? Ist es Steffen?), darüber hinaus lohnt es sich auch bei ganzzahligen Werten direkt mit dem Wert zu vergleichen, anstatt es roh in eine Bedingung zu schmeißen (wenn die Sprache das erlaubt), weil es durchaus unterschiedliche Konventionen gibt, welcher Wert für wahr oder falsch steht.
Explizite Vergleiche sind
nicht sinnvoll. In
PEP8 wird dies klar und deutlich abgelehnt.
Code:
# Don't compare boolean values to True or False using == .
Yes: if greeting:
No: if greeting == True:
Worse: if greeting is True:
Des Weiteren macht es auch im Zuge von Ducktyping keinen Sinn. Die Grundprämisse von Ducktyping ist ja gerade, einfach jeden Typ anzunehmen, der sich passend verhält. Jedes if-statement
wird und
muss zu einem boolean evaluiert werden. Insofern ist vollkommen unmissverständlich, dass bei "if
something:" das
something zu einem boolean evaluierbar sein muss.
Abgesehen davon wird bei Python - auch gerade wegen Ducktyping - nach "
ask for forgiveness not permission" entwickelt.
Das Argument mit den unterschiedlichen Konventionen leuchtet mir nicht besonders ein - bei booleans steht 0 für False und 1 für True bei jeder populären Hochsprache. Höchstens wenn man per Shell ausgeführte Programme auswertet, bekommt man Errorcode 0 für erfolgeriche Termination und Errcorcode 1 für aufgetretene Fehler.
Da gilt aber imho auch wieder: der Programmierer muss sich in seiner Umgebung auskennen.
Blubmann schrieb:
Ich finde solche Kommentare immer unfassbar unqualifiziert. Das sagt auch mehr über den Autor aus, als das was kommentiert werden sollte.
Das kannst du gerne - aber bist du tatsächlich der Meinung, dass es Anfängern hilft ihnen möglichst simple Beispiele zu geben, ohne große Kommentare, die absolut zum Copy&Paste verleiten? Die zusätzlich dazu auch noch
bad style sind und nicht im Geringsten den Konventionen von professioneller Softwareentwicklung erfüllen?
Ich zeige lieber einmal zu viel und einmal zu pedantisch die Fehler auf, als Anfänger mit Simplifizierungen und Halbwissen in die Welt zu entlassen.
Wenn ich auf Stackoverflow, Crossvalidated, Data Science oder einfach so in der Uni mit anderen Leuten über meinen Code, meine Lösungsansätze zu Problemen usw. rede, möchte ich auch kein einzeiliges "Hast du gut gemacht." hören, sondern konstruktive Kritik - wo sind Fehler? Was ist noch optimierbar? Nur so lernt man dazu und wird mit der Zeit besser, ansonsten kann man sich eine Diskussion auch gleich schenken und von Google copy&paste'n - hätte mehr oder minder denselben Effekt.
![[ChAoZ]](https://pics.computerbase.de/forum/avatars/s/491/491529.jpg?1618073566){kind=avatar}
