Monate einer Woche ermitteln

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

Ein ``range = xrange`` am Anfang des Moduls ist ja auch nicht ausgeschlossen...
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
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 ;)
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

wieso sieht xrange scheiße aus?

Ich finde es sehr schick.

Die plots gefallen mir btw. auch sehr gut :)
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
Zuletzt geändert von Leonidas am Mittwoch 30. Juli 2008, 09:39, insgesamt 1-mal geändert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

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
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

:( 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
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

meneliel hat geschrieben:Könnte ich denn theoretisch meherer Python-Versionen parallel betreiben?
Ja, das ist kein Problem.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

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?
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?
meneliel
User
Beiträge: 256
Registriert: Montag 25. Juni 2007, 08:35
Kontaktdaten:

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.
Antworten