splitter - Zerlegen von Sequenzen in gleiche Portionen

[Michael Schneider]

@Michael Schneider: Deiner Logik nach müsstest du konsequenterweise jedes Argument als Schlüsselwort übergeben. "splitter(s='Hallo Welt!')" liest sich aber eben doch bescheuert

Ich muss Dir dahingehend recht geben, als dass es möglich und aus meiner Sicht hilfreich wäre, um die Verständlichkeit zu maximieren. Vielleicht hätte ich besser seq statt s schreiben sollen. Nichtsdestotrotz sind Positionsargumente im Gegensatz zu Argumenten mit Vorgabewert nicht vertauschbar (außer wenn mit Schlüsselwortparametern angesprochen) und können daher nicht gleichgesetzt werden.

Schlüsselwortargumente stellen eigentlich eine Art optionale Argumente dar. "length" kann man schon als Schlüsselwort übergeben, weil die Signatur der Methode das eh vorsieht.

Deshalb würde ich sie auch nicht gleichsetzen. Eben weil die Schlüsselwortparameter beim Funktionsaufruf vertauscht oder weggelassen werden können.

Daraus sollte man aber kein Dogma machen … wenn du meinst, "Pythoneers" (wer immer das sein soll) würden das tun, dann ist eine Quelle dafür ganz angebracht.

Pythoneers habe ich als die Leute verstanden, die von Python überzeugt sind und dessen Interessen offen vertreten - so wie es Pendants für Java und Perl gibt.
Wie oben beschrieben habe ich das zum Thema "Vorteile von Schlüsselwortparametern" gelesen. Wo genau kann ich jetzt nicht sagen, aber wenn ich wieder darauf stoße, werde ich es ergänzen.

Als Dogma würde ich das nun nicht bezeichnen. Ich würde eher sagen, dass man daraus keine allgemeine Pflicht machen darf. Man braucht nicht überall Schlüsselwortparameter verwenden, muss sich aber darüber im Klaren sein, dass der Quellcode definitiv an Klarheit verliert. Wenn nicht für einen selbst, dann für andere.

Wenn man sich aber freiwillig selbst den Grundsatz legt, zumindest nicht-Standardfunktionen mit Schlüsselwortparametern (soweit bekannt) aufzurufen, dann sehe ich darin zumindest keinen Nachteil. Welcher soll das sein? Gerade im Interesse guter Lesbarkeit und schneller, sicherer Einarbeitung in fremden Quellcode stehe ich voll dahinter.

Zum Thema Umgebung: Wie lang soll das denn noch so gehen? Es ist doch eigentlich klar, dass sowas früher oder später schief gehen muss …

Bitte was soll da schiefgehen? Im Gegenteil, das ist die einzige Möglichkeit um zu garantieren, dass existierende Skripte weiterhin ausgeführt werden können.

Gruß,
Michael

[Leonidas]

Als Dogma würde ich das nun nicht bezeichnen. Ich würde eher sagen, dass man daraus keine allgemeine Pflicht machen darf. Man braucht nicht überall Schlüsselwortparameter verwenden, muss sich aber darüber im Klaren sein, dass der Quellcode definitiv an Klarheit verliert. Wenn nicht für einen selbst, dann für andere.

Wenn du dann feststellst, dass einige Funktionen in der Stdlib als Parameter ``a`` und ``b`` haben und sich nichtmal mittels Schlüsselwörtern aufrufen lassen, ändert das deine Meinung?

Ich glaube auch lunars Punkt ist dass der Coce eben nicht automatisch lesbarer wird, auch wenn du aus ``s`` ``seq`` macht ist es trotzdem unnötig viel Noise, speziell bei Funktionen bei denen man eine bestimmte Parameterreihenfolge sowieso erwarten würde.

[str1442]

Eigentlich sollte alles so gut benannt sein, daß man nicht unbedingt Keywordargumente braucht. In den seltesten Fällen übergibt man einen Wert direkt, sondern nutzt den Namen für ihn bzw nutzt eine Funktion / Klasse, die den entsprechenden Wert zurückgibt und das selbst am Namen deutlich macht, wie von cofi dargestellt. Wenn man einen Wert direkt übergibt sollte entweder kommentiert werden, was da passiert, oder es ist sowieso irgendwas triviales (oder etwas, was man hätte benennen können). An der Bennung erkennt man auch oft den Sinn. fetch_data_from_db() sollte eben nur genau das machen, und kein Password erwarten. Das liegt außerhalb der Verantwortung der Funktion. Funktionssignaturen ändern sich eben nicht absolut willkürlich. Oder sollten es in gutem Code nicht. Wenn etwas drin ist, was man nicht vermutet, gesetzt man hat genug Ahnung von der entsprechenden Funktionalität, gehört in der Regel auch nicht rein.

Dann kommt hinzu, wie von Leonidas angesprochen, das man eine bestimmte Reihenfolge (die man vom Namen erahnen können sollte) erwarten kann, idR nach der Wichtigkeit geordnet. Die meisten Funktionen, die ich gesehen habe, ordnen ihre Argumente nach Wichtigkeit. Bei dir kommt auch zuerst die Sequenz und dann die Länge, nicht andersrum.

Eine gute Benennung samt Unterteilung ist wohl das wichtigste, was ein Programmierer lernen muss. Und dann ist die generelle Verwendung von Keywordargumenten eher Lärm (wobei du recht hast, das es nicht schadet, hat man nicht sowieso eine extrem lange Signatur, was ein "Code smell" ist).

Übringens, iter() hat eine zweite Funktion, die dir vielleicht behilflich sein kann. Siehe help(iter).

EDIT: Naja, nicht allein von der Benennung. Auch vom Kontext in welchen die Definition stattfand (man wird ja wenigstens wissen, woher die Funktion kommt, ohne sich ihre Implementation anzuschauen, wie man sie definiert hat (Modulglobal, Helferfunktion, Funktion in einer Funktion um Unterfunktionalität zu übernehmen usw)) und dem Verwendungskontext.

[birkenfeld]

Wenn du dann feststellst, dass einige Funktionen in der Stdlib als Parameter ``a`` und ``b`` haben und sich nichtmal mittels Schlüsselwörtern aufrufen lassen, ändert das deine Meinung?

Das ist so falsch. Da die Parameter sich nicht als Keywords aufrufen lassen, haben sie gar keinen Namen. (Nur in den Docs muss halt irgendein Name stehen.)

[lunar]

Ich glaube auch lunars Punkt ist dass der Coce eben nicht automatisch lesbarer wird, auch wenn du aus ``s`` ``seq`` macht ist es trotzdem unnötig viel Noise, speziell bei Funktionen bei denen man eine bestimmte Parameterreihenfolge sowieso erwarten würde.

Exakt, Michael hat mich da ziemlich missverstanden

Die "Änderbarkeit" von Signaturen ist übrigens – das wollte ich noch hinzufügen – auch ein eher schwaches Argument. Ob Schlüsselwortargumente oder normale Argumente weniger Ärger machen, hängt schließlich vor allem davon ab, was man ändert. Außerdem sollte man als guter Programmierer sowieso nicht wild an den Funktionssignaturen rumspielen. Idealerweise ändert man öffentliche Schnittstellen nur vorsichtig und bei entsprechender Testabdeckung

[Leonidas]

Wenn du dann feststellst, dass einige Funktionen in der Stdlib als Parameter ``a`` und ``b`` haben und sich nichtmal mittels Schlüsselwörtern aufrufen lassen, ändert das deine Meinung?

Das ist so falsch. Da die Parameter sich nicht als Keywords aufrufen lassen, haben sie gar keinen Namen. (Nur in den Docs muss halt irgendein Name stehen.)

Ah, ok. War mir nicht bekannt dass Funktionen auch namenlose Parameter haben können.