[Python-de] Datumseingabe testen

Detlef Lannert lannert at uni-duesseldorf.de
Wed Aug 28 20:06:38 EDT 2002


Rainer Fischbach <fischbach at ecs-gmbh.de> wrote:
> nein, das closure wertet den Ausdruck einem lokalen Scope aus, in dem die
> Variablen d, m, y gebunden sind. Das soll hier ja verdeutlichen, wie sich
> die Reihenfolge der Elemente umkehrt.

Ich weiß nicht so recht, ob ich mir das für Python wünschen würde. Die
L*sp-ähnlichen Sprachen machen ja (mit Erfolg) reichlichen Gebrauch von
solchen Scopes, aber eine (nicht zu lange!) Python-Funktion mit einem
"funktionsglobalen" Scope kommt mir klarer und verständlicher vor --
OK, das ist auch wieder eine Geschmacksfrage.

> >;-) ? Falls die Reihenfolge verkehrt ist und man die Definition von
> >valid_date() nicht ändern will, kann man ab Python 2.3 vsl. auch schreiben
> >
> >    valid_date(*[int(s) for s in datum.split(".", 2)[::-1]])
> 
> das wär ganz nett. Damit hätte man endlich ein funktionales reverse. Sehr
> sprechend ist die Notation allerdings nicht.

Ich finde sie nicht schlecht: [anfang:ende:inkrement] mit den üblichen
Weglaßregeln. (Slices waren eigentlich schon lange so, wurden aber kaum
von irgendwas in dieser Form akzeptiert.)

> diese Art von Code, in dem eine Variable mal eine str und mal eine
> int-Liste ist, halte ich für bedenklich. Das ist undurchsichtig und
> fehleranfällig.

Auch darüber kann man geteilter Auffassung sein. Wenn eine Liste ein
Container ist, dessen Elemente ihren Wert ändern können, mag es auch
sinnvoll sein, daß sie ihren Typ ändern. Ob das Ganze undurchsichtig
und fehleranfällig wird, hängt IMO mehr von der Übersichtlichkeit der
ganzen Funktion ab.

> Die Ausnahmebehandlung ist an dieser Stelle sicher nicht
> sehr sinnvoll. Bei der ganzen Sache kann ja noch viel mehr schief gehen als
> die int-Konversion

Vielleicht habe ich nicht deutlich genug gemacht, daß das kein
Produktionscode war, sondern nur ein paar Programmzeilen, die zeigen
sollen, was ich meine. Der exakte ursprüngliche Kontext ist in den
zahlreichen Followups ja eh verlorengegangen.

Nichtsdestowenigertrotz meine ich, daß die Fehler bei der int-Konversion
explizit behandelt werden sollten, da sie zu erwartende Eingabefehler
sind. Ob die Felder dann numerisch sind oder ob das maxsplit dazu
geführt hat, daß in der Jahreszahl Punkte dringeblieben sind, merkt ja
hoffentlich die valid_date-Routine, und diese Fehler müssen auch
irgendwie behandelt werden. (Ja, und in der Praxis sollte man den
Rückgabewert von valid_date() tatsächlich verwenden, und, und ...)

> Stackless könnte hier Verbesserungen
> bringen (wie z. B. Schwanzrekursions-Elimination, etc.)

Schwanzrekursiv würde ich in Python nur programmieren, wenn Stackless
in die offizielle Version aufgenommen ist ... und danach sieht es zur
Zeit leider gar nicht aus. Aber das ist eigentlich ein anderes Thema.

  Detlef




More information about the Python-de mailing list