maxwell hat geschrieben:Was meinst du mit Protokolle genau?
Sowas wie Interfaces nur eben ohne formale Spezifizierung. Wie das engesprochende file-like-object, das eine ``.write()``-Methode enthalten muss, damit es dem Protokoll entspricht. Antere Protokolle wären etwa das Sequence-Protokoll (list, tuple), das Number-Protokoll (int, float), Mapping-Protokoll (dict), Iterator-Protokoll. Ansonsten kann man noch das Context-Manager-Protokoll nennen (durch die Methoden ``__enter__`` und ``__exit__`` zu erkennen). Es geht quasi um ein Verhalten das ein Objekt bietet: wenn das objekt quakt, ist es eine Ente. Es muss nicht das IQuackendesVogelvieh-Interface implementieren um als Ente erkannt zu werden.
maxwell hat geschrieben:
Ebenso kennen Klassendiagramme keine Funktionen.
Bevor ich meinen Senf dazu gebe, kannst Du diese Aussage genauer machen?
Nunja, Java kennt keine Methoden die nicht zu Klassen gehören, also muss alles was besser in einer Funktion aufgehoben wäre unnötigerweise in Klassen gesteckt werden. UML kennt auch keine Funktionen, ebenfalls nur methoden:
Zur Illustration:
vs.
Code: Alles auswählen
class Adder(object):
def add(self, a, b):
return a + b
result = Adder().add(3, 4)
Steve Yegge schreibt viel wenn der Tag lang ist, aber sein
Kingdom of Nouns ist IMHO eine gelungene Lektüre zu dem Thema.
maxwell hat geschrieben:Ein aus einem Klassendiagramm abgeleiteter Entwurf enthält niemals Funktionen, Generatoren, usw
Sagst Du das? Wenn ich Dich richtig verstanden habe, dann meinst Du das konkrete implementieren der Funktionsrümpfe aus einer in UML beschriebenen Klasse?
Lunar will damit aussagen, dass UML-Klassendiagramme zu beschränkt sind, einige nützliche Konzepte aus Python darzustellen, etwa eben Funktionen oder Funktionen deren Ausführung gestoppt werden kann und später wieder aufgenommen werden kann (Generatoren).
maxwell hat geschrieben:Zudem verzichtet die Syntax von Python auf allerlei Boilerplate-Konstrukte
Was ist mit importen? Ist das kein boilerplate-code? Die können u.U. ähnlich Aufwendig sein. Zumal mit unter auch Rückwärtkompatibilität eine Rolle spielt. ´Queue´ (PyVersion 2.7) vs. ´queue´ (PyVersion 3.0) und anschließendem try/except.
Nein. Wenn ich mich richtig erinnere ist in Java der ganze Classpath geladen und die ``import``-Statements sind nur defür da, dass man eine Referenz auf die Klassen bekommt. In Python werden bei einem Import die Module erst geladen, d.h. zur Laufzeit des Programmes und nicht zur Compilezeit. Somit machen die ``import`` Statements in Python wirklich etwas wesentliches und man kann nicht einfach auf sie verzichten. Boilerplate ist ja üblicherweise solcher Code der geschrieben wird, aber keinen weiteren Nutzen bringt (bzw. man hätte den Nutzen gerne als Standardverhalten, statt als Option). Das Erben von ``object`` in Python 2.x könnte als Boilerplate durchgehen, praktischerweise ist das in Python 3.x das Standardverhalten geworden.
Achja, 2to3 existiert, also musst du nicht zwischen queue und Queue unterscheiden.
