Aus Summen kürzen nur die Dummen

[snafu]

Erstmal würde man bei meiner Version wie gesagt alles durchlaufen bis zu einem Fehler/Exception sobald ein String erkannt wird und dann nochmal neu anfangen und außerdem machen `join()` und `sum()` 2 grundsätzlich unterschiedliche Sachen. Lunar hat das ja schon im Detail erläutert.

Ich find's eigentlich ganz gut, so wie es jetzt ist. Etwas ungewöhnlich finde ich nur, dass der Trenner nicht als Argument innerhalb der Klammer übergeben wird, sondern eben am Anfang stehen muss. Der Hintergrund ist klar: `join()` ist eine Methode der `str`-Klasse. Die Frage ist aber, ob das wirklich so sinnvoll gewählt ist...

[veers]

Aber was spricht denn eigentlich dagegen, sum für Strings zuzulassen?

Man kann Zeichenketten nicht addieren

Code: Alles auswählen

In [1]: hasattr(str, "__add__")
Out[1]: True

Jonas

[lunar]

Danke, dass du meine Argumentation kaputt gemacht hast.

[birkenfeld]

Ich kenne die genaue Implementierung von `sum()` nicht, aber höchstwahrscheinlich wird der `TypeError` da auch erst geworfen, wenn die 1 Million Elemente durchlaufen wurden und er auf einen String stößt.

Und das ist nicht nur höchstwahrscheinlich, sondern sicher flasch. Viel einfacher: die Exception muss man nur auslösen, wenn das zweite Argument ein String ist.

Vielleicht tobt da ja intern irgendein Kampf, ob man Strings nun annehmen sollte oder nicht.

Glaub mir, da haben wir ganz andere Sachen zu tun...

[Leonidas]

Also soll quasi die Funktion erraten was du vor hast? Das klingt nach einer sehr schlechten Idee. Explicit is better than implicit.

Wieso erraten?
Eindeutig definiert:
Sind Strings vorhanden, werden Strings addiert.
Sind (nur) Zahlen vorhanden, werden die Zahlen summiert.
Ist beides vorhanden, wird alles als String angesehen und addiert.

Und was wenn Tupel, Dicts, Listen, eigene Datentypen drin sind, die ``__add__`` definieren, aber eine Addition mit Strings unsinnig ist?

[snafu]

@birkenfeld:

Welches zweite Argument? Wenn ich `[1,2,3,'x']`übergebe, dann ist es das vierte Element der Liste, das "stört". Und Python wird doch wohl so lange addieren bis ein Fehler auftritt, da es schlecht wissen kann, ob bzw wann ein Typ auftritt, der nicht passt. Was ich meinte war: Bei Übergabe einer Liste an meine Funktion unter der Annahme, dass 1 Million Elemente vorhanden sind und erst das letzte ein String ist, würde zunächst `sum()`sein Glück versuchen, am Ende einen Fehler werfen und dann müsste nochmal `join()`durchlaufen, was natürlich viel länger dauert als sofort `join()`aufzurufen. Ich sehe ehrlich gesagt nicht, was daran falsch sein soll. Oder weiß Python schon bevor irgendwas passiert, dass die Liste Strings enthält?

[BlackJack]

@snafu: Schlimmer noch: `sum()` könnte "die Liste" eventuell auch gar nicht zweimal durchlaufen, weil die Funktion jedes "iterable" als Argument nimmt, und damit der Vorgang des Durchlaufens gar nicht wiederholbar sein muss.

[snafu]

Dass `sum()` die Liste zweimal durchläuft habe ich nicht gesagt. Ich sprach davon, dass meine *eigene* Funktion mit dem try-except sozusagen die Liste bis zum String durchlaufen müsste (mittels `sum()`) und dann von vorne anfängt (mittels `join()`). Und klar wird über die Liste iteriert, was auch sonst? Ich bezog mich einfach nur auf Noctas Überlegung, was wäre wenn `sum()` (also quasi `new_sum()`) auch Strings annähme. Und ich weiß ja nicht ob ich mich heute so unverständlich ausdrücke, aber diese Funktion müsste *natürlich* vorher wissen, ob sie es mit reinen Zahlwerten zu tun hat oder ob auch Strings in der Liste vorkommen, weil dann eben anders verfahren werden muss. Und das kann nur gehen, wenn ich entweder vorher alle Elemente einer Typprüfung unterziehe oder es eben durch probieren bemerke und bei einem Fehler das `join()`-Verfahren wähle.

[birkenfeld]

Dass `sum()` die Liste zweimal durchläuft habe ich nicht gesagt. Ich sprach davon, dass meine *eigene* Funktion mit dem try-except sozusagen die Liste bis zum String durchlaufen müsste (mittels `sum()`) und dann von vorne anfängt (mittels `join()`). Und klar wird über die Liste iteriert, was auch sonst? Ich bezog mich einfach nur auf Noctas Überlegung, was wäre wenn `sum()` (also quasi `new_sum()`) auch Strings annähme. Und ich weiß ja nicht ob ich mich heute so unverständlich ausdrücke, aber diese Funktion müsste *natürlich* vorher wissen, ob sie es mit reinen Zahlwerten zu tun hat oder ob auch Strings in der Liste vorkommen, weil dann eben anders verfahren werden muss. Und das kann nur gehen, wenn ich entweder vorher alle Elemente einer Typprüfung unterziehe oder es eben durch probieren bemerke und bei einem Fehler das `join()`-Verfahren wähle.

Mit Listen mit "gemischtem" Typ funktionieren weder `sum()` noch deine Version.

[snafu]

Dass `sum()` nur mit Zahlen funktioniert, dürfte eigentlich längst deutlich geworden sein. In meiner Version müsste man halt im except-Block die Elemente der Liste noch zu Strings mappen. Es ging ja auch einfach nur um die Überlegung, dass ein `sum()`, welches Strings annehmen kann, deutlich langsamer wäre als wenn man solche Sequenzen direkt an `join()` gibt.

[BlackJack]

`sum()` funktioniert mit allem was `__add__()` implementiert *ausser* Zeichenketten. Weil die Implemementierung darauf explizit prüft.