Seite 1 von 2

Verfasst: Samstag 26. Juli 2008, 17:10
von birkenfeld
Ein ``range = xrange`` am Anfang des Moduls ist ja auch nicht ausgeschlossen...

Verfasst: Samstag 26. Juli 2008, 18:30
von lunar
sma hat geschrieben:Es erinnert nur daran, dass range() keine so gute Idee war, man dies aber nicht ändern wollte (xreadline ist noch so ein Kandidat) und schreit jedes Mal heraus, dass Python Designfehler mit sich herumschleppt.
Welche Sprache tut das nicht ...
Daher benutze ich wenn es nicht wirklich zeitkritisch ist lieber range().
Naja, es muss schon sehr "zeitkritisch" sein, bevor sich die Performance bei so kleinen Werten auswirkt ;) Ich habe ja auch nur gemessen, weil ich wissen wollte, ob "range" tatsächlich wider meine Erwartung schneller ist als xrange, weil ich mir das nicht vorstellen konnte. Würde ich auf reine Laufzeit wert legen, wäre ich nicht Python-Programmierer ;)

Code muss gut und elegant aussehen, schön zu lesen und leicht verständlich sein. Zu Gunsten dieses ehren Ziels opfere ich gerne die eine oder andere Millisekunde ;) Obwohl ich jetzt "xrange()" auch nicht so hässlich finde ...
xrange() sollte sich ja auch Ende des Jahres mit Python 3.0 erledigt haben... ich hoffe jedenfalls auf einen schnellen Wechsel zu Python 3
Ich halte es für ziemlich unwahrscheinlich, dass sich Python 3.0 so schnell durchsetzen wird. Ich glaube, du wirst auch nächstes Jahr noch mit "xrange" leben müssen ;)

Verfasst: Sonntag 27. Juli 2008, 00:18
von Leonidas
sma hat geschrieben:Ich finde ja: xrange() sieht einfach häßlich aus. Es erinnert nur daran, dass range() keine so gute Idee war, man dies aber nicht ändern wollte (xreadline ist noch so ein Kandidat) und schreit jedes Mal heraus, dass Python Designfehler mit sich herumschleppt.
Naja, range() war für die Zeit in der es eingeführt wurde durchaus eine gute Idee, nur Python hat sich weiterentwickelt und range() blieb stehen.
sma hat geschrieben:ich hoffe jedenfalls auf einen schnellen Wechsel zu Python 3 und nicht so ein Krampf wie bei Java, wo auch noch Jahre nach dem Erscheinen von Java 5 immer noch generische Typen die Ausnahme bilden.
Naja, Java 5 blieb ja abwärtskompatibel und generische Typen haben einfach wenig Programmierer-Zulauf, Python 3 ist das nicht und wenn wir bis 2010 eine breite Adaptationsrate sehen werden, würde ich das schon als gute Geschwindigkeit ansehen. Wenn ich mal gucke, wie lange es gedauert hat, bis Python 2.5 in die wichtigsten Distributionen gebraucht hat um Jahre nach dem Release mal die Standard-Python-Version zu werden. Die Python-Entwickler schließen ja ein Python 2.7 soweit ich noch aktuell bin, gar nicht aus. Ich für meinen Teil hoffe darauf, dass es nicht soweit kommen wird, aber man wird ja sehen.

Verfasst: Dienstag 29. Juli 2008, 12:32
von meneliel
wieso sieht xrange scheiße aus?

Ich finde es sehr schick.

Die plots gefallen mir btw. auch sehr gut :)

Verfasst: Mittwoch 30. Juli 2008, 01:00
von Leonidas
meneliel hat geschrieben:wieso sieht xrange scheiße aus?
Wegen dem ``x`` am Anfang, was ja nichts zur Bedeutung der Funktion beiträgt.

Auf die gleiche Weise wie ``zdir()``, ``tzip()`` ``gprint()`` etc hässlich wären wenn es sie gäbe. ``izip()`` und die restlichen Itertools sind da eine Ausnahme, da das ``i`` tatsächlich auch für etwas steht.

Edit: Typos.

Verfasst: Mittwoch 30. Juli 2008, 09:14
von sma
Leonidas trifft den Punkt. Zur Verbreitung von Python 3.0: Ich hoffe halt und werde versuchen, es zu treiben. Ich möchte schon das neuste (und hoffentlich beste) nutzen und nicht noch jahrelang mit irgendwelchen alten Versionen.

Das Problem, das ich bei Python genauso wie bei Java sehe ist, dass die jeweils alte Version eigentlich gut genug ist und bekanntlich ist "gut genug" ja der Feind des Besseren :)

Stefan

Verfasst: Mittwoch 30. Juli 2008, 09:58
von meneliel
:( Ich werde kaum zu Python 3.0 wechseln können.
Im Moment bin ich sogar an 2.4 gebunden, mit der neuen Version 9.3 von ArcGIS kann ich dann wohl zum Glück aber auf 2.5 wechseln.

Doof ist: ich brauch halt nicht immer Python zusammen mit ArcGIS, aber oft. Und bevor ich ein Script habe, was mit 2.4 läuft, das nächste mit 2.5 bleib ich konsequent auf einer Version. :(

Könnte ich denn theoretisch meherer Python-Versionen parallel betreiben? Aber dann bräuchte ich alleine für Python mehrere Workspaces für MyEclipse... :S

Verfasst: Mittwoch 30. Juli 2008, 09:59
von Leonidas
meneliel hat geschrieben:Könnte ich denn theoretisch meherer Python-Versionen parallel betreiben?
Ja, das ist kein Problem.

Verfasst: Montag 4. August 2008, 15:51
von meneliel
Hallo,

ich benutze gleich mal den Thread, weil es zum Schluss dann auch darum ging.

Wie starte ich ein Script unter 2.4, wenn gleichzeitig 2.5 installiert ist?

Verfasst: Montag 4. August 2008, 16:40
von lunar
meneliel hat geschrieben:Wie starte ich ein Script unter 2.4, wenn gleichzeitig 2.5 installiert ist?
"python2.4 my_script.py" oder was wolltest du jetzt hören?

Verfasst: Dienstag 5. August 2008, 09:58
von meneliel
ja nee, sorry.

Hab inzwischen festgestellt, dass das Problem nicht bei Python liegt, sondern für cx_oracle local der Instantclient, also die dll fehlte. Bis ich darauf gekommen bin, dass das Problem nicht 2 parallele Python-Versionen waren, sondern Oracle, das dauerte ne Weile.