Welche Python version benutzt ihr?

[BlackJack]

@DasIch: Natürlich ist nicht-umsteigen eine Äusserung, die man auch als Protest deuten kann. Nicht bei jedem privaten Quelltext oder Miniprojekt, aber wenn zum Beispiel die wxPython-Leute einfach nicht umsteigen, dann ist das schon eine Aussage. Und wenn das viele Leute machen, übt das auch einen gewissen Druck aus. Ist halt keine laute Demo mit Sprechchören und Trillerpfeifen, sondern eher ein Schweigemarsch.

Und in gewisser Weise sage ich es ja auch, und auch einige andere, nämlich immer dann, wenn ein Neueinsteiger fragt, womit er anfangen soll, und als Antwort bekommt, doch lieber erst einmal bei der "noch nützlicheren" 2er-Reihe zu bleiben.

[Leonidas]

Gerade bei dem Argument "einfacher geworden" stösst mir der Wegfall von `cmp()` sauer auf. Um das gleiche Verhalten wie beim alten `__cmp__()` zu bekommen, muss ich jetzt plötzlich `__eq__()` und `__neq__()` und `__lt__()` und `__gt__()` implementieren.

Also ich finde das implementieren dieser Sachen irgendwie einfacher, weil mir dieses -1/0/1 bei ``cmp()`` sowieso nie gefallen hat.

Zudem man sich da auch relativ simpel mit einer Mixin-Klasse behelfen kann, wenn man das alte Verhalten wiederhaben will:

Code: Alles auswählen

class OldStyleCmp:
    def __eq__(self, other):
        return self.__cmp__(other) == 0

    def __neq__(self, other):
        return self.__cmp__(other) != 0

    def __lt__(self, other):
        return self.__cmp__(other) < 0

    def __gt__(self, other):
        return self.__cmp__(other) > 0

class Parent:
    pass

class Child(Parent, OldStyleCmp):
    def __cmp__(self, other):
        return 0

print(Child() == Child())

(Implementation unvollständig, aber es geht mir mehr darum es zu veranschaulichen)

[BlackJack]

@Leonidas: Was ist daran einfacher? Und welches -1/0/1? Damit kommt man doch so gut wie nie in Berührung, denn es gibt ja `cmp()`. Und eben bei 3.x nicht mehr, also wird da auch die Implementierung von `__cmp__()`, um die Du Dich bei dem Beispiel "gedrückt" hast, eklig. Mal als Beispiel:

Code: Alles auswählen

    def __cmp__(self, other):
        return cmp((self.a, self.b), (other.a, other.b))

Wie sähe das in 3.x jetzt bitte "einfacher" aus?

[Pascal]

es gibt bestimmt auch mehrere, die mit 2 Versionen arbeiten.

ich muss ich der Schule 2.4 nutzen, zu Hause nehme ich 2.6

[jbs]

es gibt bestimmt auch mehrere, die mit 2 Versionen arbeiten.

ich muss ich der Schule 2.4 nutzen, zu Hause nehme ich 2.6

ist das nicht oldstable?

The cmp() function should be treated as gone, and the __cmp__() special method is no longer supported. Use __lt__() for sorting, __eq__() with __hash__(), and other rich comparisons as needed. (If you really need the cmp() functionality, you could use the expression (a > b) - (a < b) as the equivalent for cmp(a, b).)

Dementsprechend muss ich ja nur ``__eq__`` und ``__lt__`` implementieren, oder?

[BlackJack]

@jbs: Nur wenn Du nur ``a == b`` und ``a < b`` schreiben können möchtest. Solltest Du auch ``a != b`` oder ``a > b`` vorhaben, müssen auch ``__neq__()`` und ``__gt__()`` für `a` implementiert sein. Und selbst wenn man das nicht explizit vorhat, fände ich "vergleichbare" Objekte, die nur die Hälfte können, sehr eigenartig, was zumindest bei mir darauf hinauslaufen würde, dass ich immer alle implementiere, auch wenn die Hälfte davon im Grunde immer gleich aussieht. Und dass ist dann halt der "boilerplate code", den ich als Verschlechterung ansehe. Dass man den als Mixin schreiben kann, macht es in meinen Augen nicht besser.

[jbs]

Ich war davon ausgegangen, dass wenn man ``lt`` und ``eq`` implementiert, der Rest automatisch ermittelt wird. Ich hab die Doku da nicht gründlich genug gelesen.

Immerhin muss man nicht ``neq`` implementieren, wenn man schon ``eq`` hat.

So finde ich das auch nicht schön.

[CM]

Ein solches Verhalten würde meines Erachtens nur dann Sinn machen, wenn man es auch bekanntgibt. Ansonsten sieht es einfach aus wie naja Bequemlichkeit und / oder Langsamkeit.

Oder -zeitliches, an der Komplexität scheiterndes- Unvermögen. Also, was die Module angeht, die ich meistens benutze (numpy, scipy, etc.) gibt es so viele C-Abhängigkeiten, dass es einfach noch eine ganze Weile dauern wird - und das ist auch in der Community bekannt. Und was die meisten Leute anbelangt (mich eingeschlossen): Sie können da kaum helfen (zu wenig Zeit, zu komplexer Code, zu viel fremder Code zum Einarbeiten).

[Pekh]

Ein solches Verhalten würde meines Erachtens nur dann Sinn machen, wenn man es auch bekanntgibt. Ansonsten sieht es einfach aus wie naja Bequemlichkeit und / oder Langsamkeit.

Oder -zeitliches, an der Komplexität scheiterndes- Unvermögen. Also, was die Module angeht, die ich meistens benutze (numpy, scipy, etc.) gibt es so viele C-Abhängigkeiten, dass es einfach noch eine ganze Weile dauern wird - und das ist auch in der Community bekannt. Und was die meisten Leute anbelangt (mich eingeschlossen): Sie können da kaum helfen (zu wenig Zeit, zu komplexer Code, zu viel fremder Code zum Einarbeiten).

Eben. Ein Boykott durch Nicht-Umstieg würde überhaupt nicht auffallen und somit seine Wirkung verfehlen. Wenn man boykottiert, muß man es schon an irgendeiner Stelle sagen. Gerade dann, wenn es auch eine Vielzahl von anderen Gründen für die "Verzögerung" geben könnte. Aber wie gesagt: Mir ist noch nichts dergleichen unterkommen - allerdings bin ich auf den entsprechenden Seiten auch eher selten unterwegs.