proggen.org

Was mir sehr gut gefällt ist die zwangsweise EInrückung, die die Klammerung ersetzt. Es zwingt den Programmierer zu einer sauberen Formatierung und man spart sich die Klammern für andere Dinge.

dani93 hat geschrieben:

Was mir sehr gut gefällt ist die zwangsweise EInrückung, die die Klammerung ersetzt. Es zwingt den Programmierer zu einer sauberen Formatierung und man spart sich die Klammern für andere Dinge.

Mit den Klammern hab ich auch so meine Probleme, da sie bei der deutschen Tastatur (fürs Programmieren) schlecht platziert sind.

dani93 hat geschrieben:Also es lohnt sich, da mal reinzuschaun?

Du kannst die Klammern ja wieder auf ü und + legen, bzw. ö und ä legen und dafür +, ü, ö und ä auf Alt-Gr 7, 8, 9 und 0. :->

#include <stdio.h>

razibu hat geschrieben:Was noch sehr empfehlenswert ist, wäre "A Byte of Python".

Was in C++ als Operatorenüberladung gelöst ist, ist in Python eine Membermethode, deren Name nicht mit dem Operator übereinstimmt. Die Operatorüberladung selbst ist letztendlich eine Memberfunktion, die allerdings als Bezeichner den entsprechenden Operator erhält. Das gefällt mir an Python nicht.

dP. hat geschrieben:

Was in C++ als Operatorenüberladung gelöst ist, ist in Python eine Membermethode, deren Name nicht mit dem Operator übereinstimmt. Die Operatorüberladung selbst ist letztendlich eine Memberfunktion, die allerdings als Bezeichner den entsprechenden Operator erhält. Das gefällt mir an Python nicht.

Was genau stört dich daran? Mir ist das noch nie negativ aufgestoßen. Ob die Methode, die ich überlade __add__ oder operator+ heißt, ist doch erstmal egal. Gut, ich kann keine Operatoren als freie Funktionen schreiben. Aber da weiß ich auch nicht, wie das in Python gelöst werden sollte. Wie kriegt der Interpreter denn raus, welcher Operator jetzt wirklich aufgerufen wird?

Genauso, wie ein Compiler!?

def __add__(a, b):
    return a + b

def __add__(a, b):
    return a - b

a = MyNumberType(3)
b = AnotherNumberType(4)

c = a + b

a = MyNumber(5)
a + 3 # funktioniert
3 + a # TypeError

Es geht mir um die Frage der Definition eines überladenen Operators. Und hier finde ich die Syntax eher bescheiden, bei C sage ich dass ich einen Operator überladen möchte und welchen. Bei Python muss ich mir eine Zuordnung zwischen Operator (+ == add) und diese ätzenden Unterstriche, die ich so auch ablehene.

dP. hat geschrieben:

Genauso, wie ein Compiler!?

Code: Alles auswählen

def __add__(a, b):
    return a + b

def __add__(a, b):
    return a - b

a = MyNumberType(3)
b = AnotherNumberType(4)

c = a + b

Was steht in c?

ResultingType operator + (MyNumberType & lhs, AnotherNumberType & rhs ) { return ResultingType( lhs.Value + rhs.Value ); }
ResultingType operator + (AnotherNumberType & lhs, MyNumberType & rhs ) { return rhs + lhs; } // Kommutativgesetz

dP. hat geschrieben:und woher weiß der Interpreter, welches __add__ er nehmen soll, wenn man keine Funktionen an Hand von Typen überladen kann? Daher finde ich es hier ganz richtig, dass man nur die Möglichkeit einer Überladung in der Klasse hat.

dP. hat geschrieben:Was dumm ist:

Code: Alles auswählen

a = MyNumber(5)
a + 3 # funktioniert
3 + a # TypeError

dP. hat geschrieben:

Es geht mir um die Frage der Definition eines überladenen Operators. Und hier finde ich die Syntax eher bescheiden, bei C sage ich dass ich einen Operator überladen möchte und welchen. Bei Python muss ich mir eine Zuordnung zwischen Operator (+ == add) und diese ätzenden Unterstriche, die ich so auch ablehene.

Gut, über Geschmack lässt sich streiten. Bei Python bedeutet ein führender Bodenstrich halt 'Achtung, Objektinterna' und zwei führende Bodenstriche das selbe, nur dass die Namen noch verändert werden. Damit es bei Vererbung keine Probleme gibt. Schon sinnvoll die Regel, aber gerade bei häufigen Methoden wie __init__, die man auch mal von ausserhalb einer Klasse aufruft, schon unschön.

In C nix, da kann man keine Operatoren überladen.

Ich habe auch nie behauptet, dass ich die schwache Typisierung in Python in irgendeiner Form gutheißen würde.