Python 2.5

mr.hide · Dienstag 25. April 2006, 17:15

Hi,

ich habe gehört das "bald" Python 2.5 rauskommen soll.
es gibt auch schon eine Snapshot Version meines Wissens nach.

Besonders interessant ist, dass 2.5 eine kleine SQL DB integriert haben wird.

Ich plane ein größeres Softwareprojekt und dass würde ich gern gleich mit 2.5 Implementieren. Auch die SQL DB kommt mir da entgegen.

Mein ihr man kann mit der schon entwickeln?
Soll ja nicht so stabil sein, oder bezieht sich das nur auf die Performance?

mitsuhiko · Dienstag 25. April 2006, 17:20

Mein softlink zeigt schon seit einiger Zeit auf python2.5. Schon seit einem Monat und noch keine Fehler gefunden. Stable ist sie sicher noch nicht, und ich halte meinen Code auch bedingt abwärtskompatibel, dh ich nutze die neuen python2.5 features noch nicht mehr als zu Testzwecken.

Die in python2.5 mitgelieferte db ist sqlite3, die gibts auch schon für python2.2 oder höher.

jAN · Dienstag 25. April 2006, 17:21

ich weis nicht... ich hab die 2.5 bei mir installiert und es läuft prima... als db ist soweit ich weis nur sqlite3 mit on board...
kannst du dir ja mal runterladen und ausprobieren
http://www.python.org/download/releases/2.5/

mr.hide · Dienstag 25. April 2006, 17:38

hmm also könnte ich auch 2.4 mit sqlite3 nehmen und dann später problemlos auf 2.5 umsteigen.

Werd ich wohl so machen müssen Rpy und PyQT gibts noch nicht für 2.5 - schade ...

Leonidas · Dienstag 25. April 2006, 21:46

mr.hide hat geschrieben:hmm also könnte ich auch 2.4 mit sqlite3 nehmen und dann später problemlos auf 2.5 umsteigen.

Ja. Nebenbei finde ich das Bindung zu SQLite, PySQLite sehr gelungen und mit stabilitätsproblemen hatte ich noch nie zu kämpfen. Wenn es die gäbe, würde es nicht aufgenommen werden.

antimicro · Mittwoch 26. April 2006, 08:07

ctypes ist nicht zu verachten!
http://docs.python.org/dev/whatsnew/whatsnew25.html

Sehr schön wenn das ab 2.5 'mit drin' ist:)

Leonidas · Mittwoch 26. April 2006, 14:29

antimicro hat geschrieben:Sehr schön wenn das ab 2.5 'mit drin' ist:)

Hihi, auf der pygame Mailingliste hatten sie schon die Idee, SDL über ctypes zu wrappen und OpenGL ebenso. Na dann bin ich mal gespannt

BlackJack · Mittwoch 26. April 2006, 22:06

Ungefähr vor einem halben Jahr wurde bei PyOpenGL ein ctypes-Branch angelegt. Ich weiss aber nicht was daraus geworden ist. Die Idee finde ich nicht schlecht, weil ich bei meinem aktuellen Python kein PyOpenGL übersetzt bekommen habe, wegen fürchterlicher Probleme mit verschiedenen SWIG Versionen.

Clython · Donnerstag 27. April 2006, 20:59

Kann mal jemand auf dummdeutsch erklären was das bringen soll? Aus euren Kommentare lese ich, dass dies möglicherweise Geschwindigkeitsgewinn bedeutet, aber bei was für einem Aufwand?

Leonidas · Donnerstag 27. April 2006, 21:04

Clython hat geschrieben:Kann mal jemand auf dummdeutsch erklären was das bringen soll? Aus euren Kommentare lese ich, dass dies möglicherweise Geschwindigkeitsgewinn bedeutet, aber bei was für einem Aufwand?

Das ctypes integriert wird? Nein, schneller wirds vermutlich nicht werden, eher langsamer. Aber wenn PyOpenGL ctypes nutzt, muss man kein C mehr für den Wrapper schreiben und somit ist es einfacher, daran zu Entwickeln. Zudem hat es noch den Vorteil, dass es portabler ist und auch die Kompilier-Stufen unnötig werden. Somit kann man PyOpenGL auch locker aus dem Sourcen verwenden wenn man keinen Compiler hat, was unter Windows oft der Fall ist.

Es ist klar, das das nicht nur Vorteile sind, sonst würden alle ctypes benutzen, was es ja schon seit langem gibt.

BlackJack · Donnerstag 27. April 2006, 22:02

Der Entwickler von PyOpenGL hat einen Blogeintrag über die Vorteile. Unter anderem hat er auch immer Probleme mit SWIG und das man oft genau die SWIG Version benötigt die der Programmierer der Anbindung benutzt hat. Und zwar bis auf die Patchlevel-Komponente der Versionsnummer. Er spart sich mit `ctypes` Arbeit, wälzt den Low-Level-Abindungskram an den Entwickler von `ctypes` ab und bekommt dann wahrscheinlich auch weniger genervte Anfragen von Leuten die PyOpenGL mit SWIG nicht kompiliert bekommen.