Verfasst: Freitag 1. Februar 2008, 13:46
@boid: Tupel sind im Grunde wie Listen, nur dass man sie nicht verändern kann. Es gibt einen kleinen Speicherplatzvorteil, weil Tupel, da nicht veränderbar, keinen Platz für spätere `append()`-Operationen "überbelegen", aber das ist hier ziemlich teuer erkauft, weil Du das `append()` ja recht häufig brauchst und es bei Tupeln halt von der Laufzeit echt ungünstig ist.
Auch bei einer `__readHeader()` braucht man keine extra `get`-Methode wenn die das Ergebnis an das Attribut `header` bindet. Wobei die zwei Unterstriche etwas übertrieben sind, wenn nicht gar schlechter Entwurf. Zwei führende Unterstriche sind dazu da, um Namenskollisionen in Unterklassen oder "Mixin"-Klassen zu vermeiden und nicht um so eine Art `private` wie in C++/C#/Java zu erzwingen. `private` ist in Python per Konvention *ein* führender Unterstrich. Das sagt anderen Programmierern, dass ist ein Implementierungsdetail, benutzen auf eigene Gefahr.
Meine Kritiken sind meistens kurz, knapp und technisch. Bitte nicht in den falschen Hals bekommen, ist wirklich nett gemeint und nicht als Angriff. Natürlich kann man nicht alles in der Standardbibliothek kennen, gerade als Einsteiger in die Sprache.
Auch bei einer `__readHeader()` braucht man keine extra `get`-Methode wenn die das Ergebnis an das Attribut `header` bindet. Wobei die zwei Unterstriche etwas übertrieben sind, wenn nicht gar schlechter Entwurf. Zwei führende Unterstriche sind dazu da, um Namenskollisionen in Unterklassen oder "Mixin"-Klassen zu vermeiden und nicht um so eine Art `private` wie in C++/C#/Java zu erzwingen. `private` ist in Python per Konvention *ein* führender Unterstrich. Das sagt anderen Programmierern, dass ist ein Implementierungsdetail, benutzen auf eigene Gefahr.
Meine Kritiken sind meistens kurz, knapp und technisch. Bitte nicht in den falschen Hals bekommen, ist wirklich nett gemeint und nicht als Angriff. Natürlich kann man nicht alles in der Standardbibliothek kennen, gerade als Einsteiger in die Sprache.