Welche Python version benutzt ihr?

[INFACT]

Welche Python version benutzt ihr?

Ich benutze immer noch 2.5, weil ich mich da besser auskenne als in python3 und es schneller als 2.6 ist.

[Dav1d]

ich nutze das 2.6.2 weil ich mit dem begonnen hab und weil es mir für py 3.1 eine lib nicht gibt die ich umbedingt brauche

[cofi]

2.6, Context Manager will ich nicht mehr missen.

[CM]

Schon wieder?
(Aber mein Pünktchen habe ich gemacht - vielleicht könnt Ihr ja doch was damit anfangen ...)

[snafu]

2.6.4, weil's in Ubuntu ist und weil es ein paar nette Features dazu bekommen hat. Der Geschwindigkeitsunterschied ist mir persönlich relativ latte.

[jens]

Wenn wir schon beim Thema sind: Hoffe nicht das Python 3.x ein großer Flop wird, aber irgendwie hab ich das Gefühl das es genau das ist. Zu wenige externe Module gibt es dafür. Zu klein der Anreiz 3.x einzusetzen, denn so viel hat sich nicht getan, oder?

[Pekh]

wxPython ist das einzige, was mich zur Zeit noch davon abhält, auf 3.1 zu gehen. Glaubt man den Entwicklern, genießt eine Anpassung an 3.x derzeit aber keinerlei Priorität. Wenn ich mich nicht irre, haben sie noch nicht einmal eine Bestandsaufnahme gemacht, was alles zu ändern wäre. Ein immer wieder zu lesendes Argument ist, daß 3.x noch nicht genügend Nutzer hat. So lange die wichtigsten Drittanbieter ihre Module nicht portieren, wird sich daran wohl auch wenig ändern. Womit sich die Katze dann wieder in den Schwanz beißt.

Nachtrag: Ich glaube, hier ist jetzt ganz klar die Community gefragt. Die meisten dieser Projekte sind ja OpenSource. Man muß wohl mal alle eigenen Projekte zurückstellen und mithelfen, daß der große Sprung geschafft wird.

[snafu]

Vielleicht verhält sich 3.1 zu 2.6 ja so wie Vista zu XP.

[gerold]

mithelfen, daß der große Sprung geschafft wird.

Hallo Pekh!

Und wenn man diesen Sprung nicht machen will? Weil einem z.B. einige Änderungen in Python 3 sowas von nicht gefallen? Vielleicht protestieren manche sogar durch "Nichtumstieg" gegen diese nichtsbringenden inkompatiblen Änderungen?

mfg
Gerold

[Leonidas]

Und wenn man diesen Sprung nicht machen will? Weil einem z.B. einige Änderungen in Python 3 sowas von nicht gefallen?

Also dass Python 3 einfacher wird, finde ich ja schonmal eine Änderung in die richtige Richtung.

[gkuhl]

Ich denke wir müssen uns nur etwas in Geduld üben. Python 3.x stable ist noch nicht einmal ein Jahr alt. In fünf Jahren sieht die Welt bestimmt ganz anders aus.

[Pekh]

mithelfen, daß der große Sprung geschafft wird.

Hallo Pekh!

Und wenn man diesen Sprung nicht machen will? Weil einem z.B. einige Änderungen in Python 3 sowas von nicht gefallen? Vielleicht protestieren manche sogar durch "Nichtumstieg" gegen diese nichtsbringenden inkompatiblen Änderungen?

mfg
Gerold

Hallo Gerold!

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. Ich bin allerdings noch auf keine derartigen "Manifeste" gestoßen. Was natürlich daran liegen kann, daß ich nicht allzu weit herumkomme. Um so mehr würden mich natürlich interessieren, was ein von mir sehr geschätzter Autor in diesem Forum konkret zu bemängeln hat. Ich gebe zu, die Liste der Neuerungen bis jetzt nur überflogen zu haben, aber was ich dort gelesen habe, sah auf den ersten Blick durchaus positiv aus.

[numerix]

Zu klein der Anreiz 3.x einzusetzen, denn so viel hat sich nicht getan, oder?

Für den, der gerne tkinter nutzt, ist 3.1 auf jeden Fall - im wahrsten Sinne des Wortes - einen Blick wert.

[DasIch]

Vielleicht protestieren manche sogar durch "Nichtumstieg" gegen diese nichtsbringenden inkompatiblen Änderungen?

Protestieren tut man um seine Meinung zu äußern, wo ist die Äußerung wenn man nicht umsteigt? Wenn du wirklich protestieren willst mach einen Fork.

[BlackJack]

@Leonidas: Mal abgesehen davon, dass ich ja sowieso noch das uralte 2.5 einsetze, gefällt mir nicht alles bei 3.0. 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.

Das jetzt in irgendwelchen Manifesten breitzutreten bringt IMHO aber nichts. 3.x ist da und wird sicher auch nicht wieder weggehen, auch wenn es nicht der Erfolg wird, den man sich davon vielleicht erhofft hat.

[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?