Hallo allerseits,
ich suche nach Testern für mein Program. Es handelt sich im wesentlichen um ein POSIX cp mit ein paar netten Features. Hier der Link zur sourceforge-Seite und ein paar Informationen:
Link: https://sourceforge.net/projects/python-copy/
FEATURES:
- teilweise kopierte Dateien werden fortgesetzt
- Dateimuster ('*.mp3') können ausgeschlossen werden
- die -i Option kopiert erst alle Dateien, deren Ziele nicht existieren und fragt erst dann nach (anstatt immer zwischendurch die Operation zu blockieren).
Die aktuelle Version ist 0.3. Die Installation ist mit 'python setup.py install' erledigt.
python-copy: commandline copy mit zusätzliches Features
-
BlackJack
@Lateralus: Nachdem ich den Schock über die Tabs statt Leerzeichen überwunden hatte 
ist mir ein Fehler bei der Vererbung aufgefallen:
``super(self.__class__, self)`` ist falsch. Das funktioniert bei Dir zufällig weil Du das nur auf der letzten Vererbungsebene verwendest. Wenn Du zum Beispiel in der Basisklasse auch ``super(self.__class__, self).__init__()`` aufrufst um `object.__init__()` auszuführen dann fällt das auf, dass es falsch ist, denn dann bekommst Du eine Endlosrekursion und einen Programmabbruch. Das erste Argument muss die konkrete Klasse sein und nicht ein dynamisches ``self.__class__`` weil das nicht dasselbe ist, sondern nur in bestimmten Fällen und die sind „zerbrechlich”.
Ich persönlich finde `super()` ja alles andere als Super. Es ist nicht einfach zu verstehen. Wenn man es an einer Stelle in der Hierarchie benutzt muss man es konsequent in jeder Klasse der Hierarchie durchziehen. Wenn man nicht garantieren kann dass nicht bei allen Methoden in so einer Kette die gleiche Signatur verwendet wird, muss man immer *args und **kwargs zur Signatur hinzufügen und durchreichen. Da man dass eigentlich *nie* garantieren kann, weil man ja nicht wirklich ausschliessen kann, dass irgendwann, irgendwer eine weitere Unterklasse ableitet und die Methode überschreibt, muss man im Grunde zu jeder Methode nur so zur Sicherheit *args und *kwargs der Signatur hinzufügen, nur um sicherzugehen dass man die Methode auch von beliebigen abgeleiteten Klassen aufrufen kann.
Und dieser ganze Aufwand und Boilerplate-Code löst dann noch nicht einmal ein Problem was man normalerweise hätte wenn man das ohne `super()` schreiben würde.
Ansonsten ist mir beim drüberschauen noch aufgefallen, dass Du viel mit numerischen Konstanten hantierst, was nicht wirklich schön/OOP ist. Ich würde die ja mindestens mal in `enum`\s zusammenfassen, oder aber die Entscheidungen die indirekt über diese Konstanten getroffen werden durch Funktionen und Objekte ersetzen.
ist mir ein Fehler bei der Vererbung aufgefallen:``super(self.__class__, self)`` ist falsch. Das funktioniert bei Dir zufällig weil Du das nur auf der letzten Vererbungsebene verwendest. Wenn Du zum Beispiel in der Basisklasse auch ``super(self.__class__, self).__init__()`` aufrufst um `object.__init__()` auszuführen dann fällt das auf, dass es falsch ist, denn dann bekommst Du eine Endlosrekursion und einen Programmabbruch. Das erste Argument muss die konkrete Klasse sein und nicht ein dynamisches ``self.__class__`` weil das nicht dasselbe ist, sondern nur in bestimmten Fällen und die sind „zerbrechlich”.
Ich persönlich finde `super()` ja alles andere als Super. Es ist nicht einfach zu verstehen. Wenn man es an einer Stelle in der Hierarchie benutzt muss man es konsequent in jeder Klasse der Hierarchie durchziehen. Wenn man nicht garantieren kann dass nicht bei allen Methoden in so einer Kette die gleiche Signatur verwendet wird, muss man immer *args und **kwargs zur Signatur hinzufügen und durchreichen. Da man dass eigentlich *nie* garantieren kann, weil man ja nicht wirklich ausschliessen kann, dass irgendwann, irgendwer eine weitere Unterklasse ableitet und die Methode überschreibt, muss man im Grunde zu jeder Methode nur so zur Sicherheit *args und *kwargs der Signatur hinzufügen, nur um sicherzugehen dass man die Methode auch von beliebigen abgeleiteten Klassen aufrufen kann.
Und dieser ganze Aufwand und Boilerplate-Code löst dann noch nicht einmal ein Problem was man normalerweise hätte wenn man das ohne `super()` schreiben würde.
Ansonsten ist mir beim drüberschauen noch aufgefallen, dass Du viel mit numerischen Konstanten hantierst, was nicht wirklich schön/OOP ist. Ich würde die ja mindestens mal in `enum`\s zusammenfassen, oder aber die Entscheidungen die indirekt über diese Konstanten getroffen werden durch Funktionen und Objekte ersetzen.
Danke für die Antwort,
habe das mit dem self.__class__ jetzt verstanden - es zeigt auf die Klasse der Instanz... Hatte es eigentlich immer nur benutzt, weil man dann darum herum kommt, zwei Stellen im Code zu ändern, wenn man Klassen oft umbenennt...
Was die Konstanten angeht, ist ein Enum vielleicht nett, ja. Das walk.py Modul ist rein prozedural geschrieben und ehrlich gesagt, bin ich ganz glücklich damit und hätte den Rest des Programmes gerne auch so geschrieben. Möglicherweise wird walk.py auch wieder stärker OO - um so mehr Features an dieser Stelle des Codes wirksam werden um so mehr Argumente muss man der Funktion übergeben und dass es dann wirklich irgendwann nervig... aber für die aktuelle Komplexität tut es den Job ganz gut.
Ist das mit den Tabs so unüblich? Ich habe schon oft darüber gelesen, wie schrecklich das sein soll, aber irgendwie habe ich dafür noch nie eine ordentliche Begründung gelesen...
habe das mit dem self.__class__ jetzt verstanden - es zeigt auf die Klasse der Instanz... Hatte es eigentlich immer nur benutzt, weil man dann darum herum kommt, zwei Stellen im Code zu ändern, wenn man Klassen oft umbenennt...
Was die Konstanten angeht, ist ein Enum vielleicht nett, ja. Das walk.py Modul ist rein prozedural geschrieben und ehrlich gesagt, bin ich ganz glücklich damit und hätte den Rest des Programmes gerne auch so geschrieben. Möglicherweise wird walk.py auch wieder stärker OO - um so mehr Features an dieser Stelle des Codes wirksam werden um so mehr Argumente muss man der Funktion übergeben und dass es dann wirklich irgendwann nervig... aber für die aktuelle Komplexität tut es den Job ganz gut.
Ist das mit den Tabs so unüblich? Ich habe schon oft darüber gelesen, wie schrecklich das sein soll, aber irgendwie habe ich dafür noch nie eine ordentliche Begründung gelesen...
-
BlackJack
@Lateralus: Die ordentliche Begründung für die Leerzeichen ist das vier Leerzeichen eine feste Breite haben während ein Tab keine feste Breite hat. Und man kann die auch nicht überall einstellen, also muss man davon ausgehen das der Quelltext in einem anderen Editor, im Terminal, im Webbrowser, in E-Mails, in anderen Werkzeugen wie grafischen Frontends zu Versionsverwaltungen und Diff/Merge-Programmen, … nicht so aussieht wie er sollte. Schau Dir Deinen Quelltext einfach mal mit einer anderen Einstellung als in Deinem Editor an, und schon sehen einige Sachen die eigentlich ordentlich ausgerichtet sein sollten, unschön und schwerer lesbar aus. Konkretes Beispiel für Dein Programm ist die Anzeige bei SourceForge wenn man dort das Repository anschaut.
Da die Style Guide Empfehlung vier Leerzeichen sind, kann man auch nicht damit argumentieren dass die meisten Werkzeuge sich an einen „Standard” halten weil der „Standard“ 8 Zeichen pro Tabstop ist.
Ein weiterer Grund ist, das man sich auf *eine* Art einigen sollte sonst wird es schwierig zusammen zu arbeiten oder Quelltext aus anderen Quellen zu übernehmen. Da ein Tab etwas anderes ist als vier oder acht Leerzeichen kann man sich sonst auch ganz leicht mal Code basteln der korrekt eingerückt aussieht, es aber nicht ist, weil Zeilen mit Leerzeichen mit solchen mit Tabs vermischt wurden.
Da die Style Guide Empfehlung vier Leerzeichen sind, kann man auch nicht damit argumentieren dass die meisten Werkzeuge sich an einen „Standard” halten weil der „Standard“ 8 Zeichen pro Tabstop ist.
Ein weiterer Grund ist, das man sich auf *eine* Art einigen sollte sonst wird es schwierig zusammen zu arbeiten oder Quelltext aus anderen Quellen zu übernehmen. Da ein Tab etwas anderes ist als vier oder acht Leerzeichen kann man sich sonst auch ganz leicht mal Code basteln der korrekt eingerückt aussieht, es aber nicht ist, weil Zeilen mit Leerzeichen mit solchen mit Tabs vermischt wurden.