Liste von Python-Quirks

[sma]

...hat hier jemand zusammengestellt: http://www.lshift.net/blog/2009/10/29/python-quirks

Nicht alles ist richtig und leider kommt ihm seine Blog-Software in die Quere, denn sie erkennt Python-Code als Formatanweisungen und macht z.B. ' ' zu ". Ist aber eine interessante Zusammenstellung mit Diskussionspotential.

Stefan

[derdon]

Another strange type is slice:

Code: Alles auswählen

>>> slice
<type 'slice'>

Und warum ist der jetzt so seltsam? Da fehlt eine Erklärung, ich bin wohl zu doof, um den Grund zu sehen.

[birkenfeld]

Ich denke, seltsam im Sinne von "sieht man eigentlich nie". Zumindest nicht explizit als "slice". Evtl. weiß der Autor auch nicht, dass dieser Slice-Typ für Subscript-Slices verwendet wird.

[sma]

Evtl. weiß der Autor auch nicht, dass dieser Slice-Typ für Subscript-Slices verwendet wird.

Denke ich auch. Aber das ist genauso wie ein IMHO unsinniger Versuch, wertfremde Datentypen miteinander vergleichen zu wollen zeigt, wie jemand da naiv (im besten Sinne) an eine Sprache herangeht und von den Ergebnissen überrascht wird. Wäre es vielleicht besser ein Fehler, wenn man prüfen will, ob "Ellipsis > slice(1, 2)" ist?

Stefan

[Darii]

Auf das Verhalten, dass in-place-Operationen None statt self zurückgeben bin ich auch schonmal reingefallen und finde dieses Verhalten immer noch dämlich.

Sein zweiter Punkt ist nicht nachvollziehbar, natürlich ist 1 = (1) und kein Tupel, wenn das nicht so wäre, hätte man bei ( 3 * (4 + 2) ) echte Probleme.

Beim Rest kann ich seine Kritik meist auch nicht so recht nachvollziehen und zeugt hauptsächlich von mangelndem Verständnis.

[birkenfeld]

Evtl. weiß der Autor auch nicht, dass dieser Slice-Typ für Subscript-Slices verwendet wird.

Denke ich auch. Aber das ist genauso wie ein IMHO unsinniger Versuch, wertfremde Datentypen miteinander vergleichen zu wollen zeigt, wie jemand da naiv (im besten Sinne) an eine Sprache herangeht und von den Ergebnissen überrascht wird. Wäre es vielleicht besser ein Fehler, wenn man prüfen will, ob "Ellipsis > slice(1, 2)" ist?

In Python 3 kannst du nur noch kompatible Typen vergleichen. Das ist meiner Meinung nach auch richtiger, als allen Objekte standardmäßig eine Reihenfolge zu geben.

Der Nachteil ist, dass man nicht einfach mehr "list.sort()" aufrufen kann, ohne sicher zu sein, dass die Liste homogen ist. Das betrifft aber hautptsächlich auch nur Code, der generische Listen bearbeitet, wie z.B. Pretty-Printer. (Allerdings hat das auch schon unter Python 2 nicht in jedem Fall geklappt, wenn z.B. mehrere komplexe Zahlen in der Liste waren. Es stand ja jedem Typ frei, __cmp__ bzw. Rich-Comparison zu definieren und auch entsprechende TypeErrors zu werfen.)