Doch, du wolltest ausdrücken, dass Slicing/Index-Notation unpraktisch wird, wenn man sie übermäßig einsetzt. Dem stimme ich zu.sape hat geschrieben:Ok, du willst nicht verstehen was ich mit dem Beispiel sagen wollte.birkenfeld hat geschrieben:[...]
Du machst es dir aber auch verdammt schwer.
elem[0][::-1][:9][::-1] == elem[0][-9:]
"gewisse Personen" ist also explizit?Soll ich jetzt eine halbe stunde überlegen um ein Beispiel zu finden das man nicht auf kleinkarierter weise widerlegen kann um das Auszusagen was diese Beispiel eigentlich schon aussagt!? Wahrscheinlich würde dann aber keine Antwort kommen wenn ich Recht habe und es hätte dann nichts gebracht, weil von gewissen Personen nur Antworten kommen, wenn Sie was widerlegen können und Sie Recht kriegen/behalten. Sachen wie "Ja hast ja Recht" kann man von Solchen Personen nicht erwarten. War das jetzt eine Wertung von mir? Ja, war es, ein explizite anstatt deine ewigen impliziten.

Okay, akzeptiert. Ich verstehe jetzt, was du gemeint hast, und dass das Beispiel dazu diente zu zeigen, was -- für dich -- "pythonisch" bedeutet, es war einfach ungeschickt gewählt.Ne darum ging es wirklich nicht. Es ging um das warum und die Antwort von mir das ich es als Pythonischer empfinde. -- Dazu sollte das obere Beispiel auch dienen aber wie gesagt, hätte ja nicht ahnen könne (oder hätte ich mal doch), das man das Beispiel wider auf kleinkarierter Art und weiße seziert und in grnde sagt "ne da kannst du auch so machen". Es war nur ein beispiel, mehr nicht!birkenfeld hat geschrieben:[...]
Es geht nicht darum, das Gleiche in zwei Weisen auszudrücken. Der Code mit replace() funktioniert anders als der mit Slicing.
Das "kleinkariert" gebe ich gerne an dich zurück, wenn mal wieder das einzige, was du an einem Stück Code zu kritisieren hast, ein überschriebenes Builtin ist.
Ich finde nicht, dass man einfach so drauflosprogrammieren sollte und sich einen Dreck um das Laufzeitverhalten scheren.In der Entwicklungszeiten ist das erstmal irrelevant:birkenfeld hat geschrieben:[...]
Hier ist es ja noch verhältnismäßig harmlos, aber das nächste Mal ist die Alternative halt zufällig O(n^2), während der "komplexe" Weg O(n) ist. Tja.
http://de.wikipedia.org/wiki/Unix-Philo ... mming_in_CTony Hoare hat geschrieben: „Zu frühe Optimierung ist die Wurzel allen Übels.“
Außerdem bin ich der Meinung, dass obiges in C mehr Zeit spart als in Python. In C ist es um ein Vielfaches schwieriger, einen komplexen Algorithmus richtig zu implementieren, inklusive aller Speicherverwaltungsdetails. Also spart man Entwicklungszeit, indem man erstmal den einfacheren verwendet, und dann erst sieht ob es damit Probleme gibt. In Python, und bei solch einfachen Problemen wie wir sie hier haben, kostet es nicht mehr Zeit, das Richtige zu tun.
Nimm es mir nicht übel, aber ich will gar nicht wissen, worum es mir eigentlich geht.Nichts für ungut, aber dir geht es eigentlich um was anderes.