re-Modul auch für "Kleinigkeiten" verwenden?

[mutetella]

Hallo,

zur Bildung eines datetime.date-Objektes benötige ich aus einem String, den ich vom argparse-Parser erhalte, die Zahlen für Jahr, Monat und Tag, z. B. für den 14. Mai 2010 die 2010, 5 und 14.

Ich erhalte vom parser den String (arg), der so ausschauen kann:

Code: Alles auswählen

'2010 5 14'
'2010 05 14'
'2010.5.14'
'2010.05.14'
'2010,5,14'
'2010, 5,14'

und so weiter und so weiter...

Gelöst habe ich das folgendermaßen:

Code: Alles auswählen

import re

def make_date(arg):
    year, month, day = [int(item) for item in re.split('\D+', arg)]
    return datetime.date(year, month, day)

Meine Frage: Ist ein import von re für so eine "Kleinigkeit" gerechtfertigt oder geht das eventuell auch mit Bordmitteln, die ich nicht kenne?
Habe schon ein wenig mit string-Methoden hantiert, war aber alles eher zu kompliziert...

Wie würdet Ihr das lösen?

Gruß
mutetella

[Hyperion]

Speziell bei Modulen aus der Standard-Lib sehe ich da keinerlei Probleme! Du erschaffst ja keine neuen Abhängigkeiten und greifst auf das richtige Werkzeug dafür zurück. Zudem bleibt Dein Code so schön lesbar.

Wenn das Format wohl definiert und einfach ist, bspw. alles durch Punkte getrennt, kannst Du natürlich darauf verzichten und etwas wie strptime() nutzen oder bei anderen Problemen eben split().

[lunar]

@mutetella: Ich würde ja einfach ein festes Format (e.g. ISO) voraussetzen und dann mit "datetime.strptime()" in ein "datetime"-Objekt übersetzen.

[mutetella]

@lunar:
Ich bin da eher der Ansicht, dass ein Programm auf den Nutzer zugehen sollte und nicht umgekehrt. Wenn ich ein Programm starte und ihm dabei noch ein Datum mit auf den Weg geben möchte, dann sollte es in möglichst weit gesteckten Grenzen mir überlassen sein, wie ich das Datum eingebe.
Sicherlich keine leichte Aufgabe, aber den Anspruch habe ich nun mal...

mutetella

[BlackJack]

@mutetella: Das ist IMHO eine schlechte Idee. Und gerade bei einer Datumseingabe sollte man gar nicht erst versuchen zu erraten, was der Benutzer da vielleicht gemeint haben könnte, sondern etwas Einfaches und Striktes vorgeben. Programme die den Benutzer "alles" eingeben lassen und dann versuchen da etwas sinnvolles heraus zu lesen, sind letztendlich auch nicht so benutzerfreundlich, weil der Benutzer früher oder später etwas eingibt, was nicht so interpretiert wird, wie *er* sich das dachte. Entweder bemerkt er es gar nicht -- dann arbeitet das Programm unbemerkt mit falschen Daten, oder er merkt es, versteht aber nicht warum ihn das Programm nicht versteht -- hat doch sonst immer geklappt.

Nehmen wir mal das Datum '01/02/03'. Sag mir mal welches Jahr, welcher Monat, und welcher Tag das ist. Machen wir es mal eindeutig: '01/02/2003' -- so jetzt ist es ganz klar der 2. Januar 2003. Oder!? Diese Überlegung führt letztlich dazu, dass man zumindest für Zahlenwerte aus denen man nicht *eindeutig* bestimmen kann was Tag, Monat, und Jahr ist, die Reihenfolge vorschreiben *muss*. Nur ist dass dann eine API wo man dem Benutzer sagt, Du kannst Weihnachten gerne so wie Du das gewohnt bist, als '12/24/99' schreiben, aber den Eintrag für den ersten Arbeitstag im darauf folgenden Jahr musst Du dann als '00-01-03' angeben, sonst wird es vielleicht nicht richtig erkannt. Meinst Du die Leute fangen dann an zwei verschiedene Schreibweisen zu verwenden oder nicht vielleicht doch lieber gleich und immer die vorgeschriebene Reihenfolge die immer richtig erkannt wird!? Und wenn man schon die Reihenfolge vorschreibt, dann ist es IMHO unnötig aufwändig dem Benutzer verschiedene Trennzeichen zu erlauben.

Da greift für mich "Refuse the temptation to guess" aus dem Python-Zen.

Wenn der Benutzer das Datum so eingeben können soll, wie er das in seiner Lebensumgebung gewohnt ist, dann kann man das ja konfigurierbar machen, also das er in den Optionen ein festes Muster vorgeben kann und dann aber auch nur Eingaben akzeptiert werden, die darauf passen.

[mutetella]

Ich bin halt sehr angetan von Programmen, die mit Benutzereingaben nicht kleinlich umgehen und mich nicht ständig maßregeln, etwas so und nicht anderst zu tun.

Aber letztlich hast Du Recht: Die für unseren Verstand so selbstverständliche Vorgehensweise, erfasste Informationen unter Einbeziehung des Kontexts dieser Informationen in eine sinnvolle Form zu bringen lässt sich wohl nur ansatzweise in einem Programm nachstellen. Zudem diese sinnvolle Form oftmals auch noch von unserer Prägung und nicht selten unserer Laune bestimmt wird. Puh... und ich will doch einfach nur, dass jemand sein Datum eingibt...

Ich denke, da ist der Kompromiss, dem Nutzer die Möglichkeit zu geben, die ihm bekannten und geläufigen Formate in der Konfiguration zu hinterlegen, ein guter Weg. Gehört innerhalb einer GUI ja inzwischen zum guten Ton. Warum also nicht auch auf Kommandozeilenebene?

mutetella

[Leonidas]

Das geht natürlich auch, kannst natürlich ne Option machen wo der User das Format zum Beispiel in der Syntax von ``strptime`` angeben kann.

[sma]

Ob man ein Datum möglichst großzügig parsen sollte, will ich nicht diskutieren. Ob man REs für derartige "Kleinigkeiten" einsetzen sollte? Unbedingt. Ich finde REs praktisch und solange man nicht unverständliche mehrzeilige Monsterausdrücke baut, ist das besser, als zu versuchen, zu Fuß nachzubauen, was REs viel besser können.

Code: Alles auswählen

for s in ['2010 5 14','2010 05 14','2010.5.14','2010.05.14','2010,5,14','2010, 5,14']:
    s = s.replace(".", " ")
    s = s.replace(",", " ")
    try:
        y, m, d = map(int, filter(bool, s.split(" ")))
    except ValueError:
        continue
    print(y, m, d)

Stefan

[mutetella]

Vielen Dank für Eure Einschätzungen und Tipps! Das hat mir mein Leben wieder mal etwas einfacher gemacht...

mutetella

@sma: Natürlich sind solche Konstrukte irgendwie irrsinnig, wenn es wie in diesem Fall Module gibt, die diese Arbeit besser erledigen können. Aber ich muss trotzdem gestehen, dass ich auf solche Routinen steh'...

[noisefloor]

Hallo,

Ich bin halt sehr angetan von Programmen, die mit Benutzereingaben nicht kleinlich umgehen und mich nicht ständig maßregeln, etwas so und nicht anderst zu tun.

Schon, aber wenn dein Programm zu 3/4 nur aus Eingabe-Validierungen und -konvertierungen besteht ist das auch nicht so prall.

Gruß, noisefloor

[mutetella]

Entscheidet sich Bedienkomfort am Engagement des Entwicklers oder gibt es Grenzsteine, an denen ich mich zu orientieren habe?
BlackJack hat da ja schon Szenarien aufgezeigt, die durchaus nachvollziehbar sind. Nur, sind solche Ecksteine wirklich Grenzsteine? Oder sollte Software hier öfters als man das bisher gewohnt ist die googlesche Frage "Meinten Sie vielleicht..." stellen, wenn Eingaben nicht validiert oder zugeordnet werden können?
Wir alle kennen Software, die sich an mancher Stelle 'zickig' verhält und erkennen lässt, dass hier nicht Bedienkomfort sondern persönliche Vorliebe (oder Faulheit/Unkreativität/Gewohnheit/Schlamperei ...) des Entwicklers auf der Blaupause standen.
Technisch affine Menschen wie wir umschiffen solche Unzulänglichkeiten relativ problemlos, oftmals fallen sie uns nicht einmal sonderlich auf. Wenn ich aber beispielsweise meine Frau beobachte, an welchen Programmpunkten sie immer wieder 'verhindert' wird, so stelle ich fest, dass hier eine Denk- und Handlungsweise vorausgesetzt wird, die von einem technisch uninteressierten Nutzer nicht erwartet werden sollte.
Wenn man sich allein einmal in OpenOffice-Foren oder auf Seiten, die Hilfestellung für Outlook anbieten umschaut, so findet man unzählige Problemschilderungen, die durch intuitiver gestaltete Bedienerführung und Dialogfenster in dieser Fülle wohl nicht auftauchen würden. Und hier meine ich nicht spezielle Probleme, sondern vermeintlich 'normale' Vorgehensweisen von Anwendern, die einfach nicht zum Ziel führten.
Bleibt die Frage: Wie weit soll ich Nutzern die Freiheit geben, ihr Datum einzugeben, wie es ihnen beliebt, ohne dadurch neue Hürden aufzubauen?

Schon, aber wenn dein Programm zu 3/4 nur aus Eingabe-Validierungen und -konvertierungen besteht ist das auch nicht so prall.

Warum?

mutetella


So, und jetzt ess' ich erst mal einen Apfel, damit ich auf andere Gedanken komme...

[Darii]

Bleibt die Frage: Wie weit soll ich Nutzern die Freiheit geben, ihr Datum einzugeben, wie es ihnen beliebt, ohne dadurch neue Hürden aufzubauen?

Gar keine, dafür verwendet man am besten spezielle GUI-Elemente alles andere ist nur nervig. Andernfalls Datumseingabe wie in locale vorgegeben oder nach ISO 8601. Das einzige sinnvolle Zugeständnis dabei ist es, den Nutzern führende Nullen und – sofern möglich – Leerzeichen zu erlassen/ignorieren.

So, und jetzt ess' ich erst mal einen Apfel, damit ich auf andere Gedanken komme...

Gute Idee, die Datumseingabe vom Apple Adressbuch oder iCal ist imo sehr gelungen.

jQuerys datepicker hingegen ist ein Beispiel wie man es nicht machen sollte (Monat und Jahr können nur durch Pfeiltasten verändert werde nicht durch direkte Eingabe, viel Spaß beim 12 Mal oder mehr klicken).

[snafu]

Wenn ein Programm wild rät, muss das aber nicht unbedingt etwas mit Bedienkomfort zu tun haben. Die Nachteile eines solchen Vorgehens hinsichtlich abzusehender Fehlinterpretationen wurden dir ja bereits aufgezeigt. Wenn für den Benutzer bei der Eingabeaufforderung klar erkennbar ist, welches Schema erwartet wird, dann schafft das auch ein Anfänger ohne große Schwierigkeiten. Und wer schon an dem Satz "Bitte geben Sie ein Datum ein (Formatbeispiel: 01.12.2010)" verzweifelt, der sollte sich vermutlich ernsthaft überlegen, ob Computer das richtige für ihn sind. Man sollte halt schon schauen, dass man es mit der künstlichen Intelligenz nicht übertreibt, wobei das Themenfeld für sich recht spannend sein dürfte (in Bezug auf psychologische Aspekte und sowas). Such mal nach dem Begriff "Maschine-Mensch-Interaktion", wenn dich sowas näher interessiert.

[Hyperion]

Was ich mir noch als sinnvoll vorstellen könnte, wäre - neben einem default Eingabeformat - die Möglichkeit, das Schema des Datums mit anzugeben, ähnlich wie strptime() das ja auch erwartet. Damit müßte man nicht raten und hätte den Parser schon gratis von Python mitgeliefert, ein Anwender, der viele daten per Scripting an Dein Programm übergeben will, hat dann den Vorteil, sein Quellformat nicht durch einen Zwischenschritt umformatieren zu müssen.

[BlackJack]

@mutetella: Einiges beruht IMHO auch auf einer Fehleinschätzung und falschen Erwartungen von Nutzern. Eine Office-Suite ist einfach nicht intuitiv bedienbar. Technisch uninteressierte Nutzer sollten nicht erwarten damit einfach so umgehen zu können. Eine Textverarbeitung ist zum Beispiel nicht einfach nur eine Software, die eine Schreibmaschine simuliert. Auf dem Niveau wird sie aber von vielen Leuten benutzt, die dann bei den Sachen, welche über die Schreibmaschine hinausgehen, oft überfordert sind, weil sie sich nicht mit den Konzepten, die hinter einer Textverarbeitung stehen, auseinander setzen können oder wollen. Das muss man aber tun wenn man das Potential einer Textverarbeitung ausschöpfen möchte, oder auch nur wenn man nicht "gegen" die Software arbeiten will. Man muss lernen was man besser dem Programm überlässt und nach welchen Regeln dort intern Entscheidungen getroffen werden. Wenn man eine Schreibmaschine möchte, dann sollte man zum Beispiel Windows `Write` benutzen.

Die "normalen" Vorgehensweisen von Anwendern, die nicht zum Ziel führen, beruhen oft auf einem falschen Bild wie die Anwendung wohl intern tickt. Man muss halt als Anwender wissen wie die Konzepte aussehen und was bestimmte Vokabeln im Programmkontext bedeuten. Das muss der Anwender lernen. Und es ist technisch. Rechner sind halt ein sehr technisches Werkzeug. Intuitiv geht da gar nichts, denn wenn man es so lösen würde wie die Anwender von denen Du sprichst es erwartet hätten, würden die auf die Nase fallen, bei denen die Vorstellung der Abläufe bisher "intuitiv" richtig war.

Man sollte es natürlich nicht unnötig schwer für Benutzer machen Daten einzugeben, also keine Datumsangaben in Sekunden seit dem 1.1.1970 verlangen, aber je mehr Freiheit man dem Benutzer lässt, um so mehr Code zum parsen und validieren benötigt man, der eine Fehlerquelle darstellt und immer weiter gepflegt werden muss. Um so mehr Dokumentation benötigt man, die dem Benutzer erklärt was er eingeben kann und was nicht. Desto mehr Mehrdeutigkeiten können sich an solchen Stellen einschleichen. Benutzer werden Sachen eingeben an die man im Traum nicht gedacht hat, die irgendwie "sinnvoll" interpretiert werden. Nach einer Programmänderung werden die dann vielleicht anders interpretiert und der Nutzer sagt "hey, hier ist ein Bug in der Software". Auf so eine Weise kann echt ekelartiger "Interpretations"-Code entstehen der Schicht um Schicht wächst und komplexer wird, bis er irgendwann undurchschaubar ist.

Ich würde einfache Benutzerschnittstellen die nicht versuchen "schlau" zu sein, sondern dem Benutzer klar sagen "das hier verstehe ich nicht, schau bitte in der Dokumentation nach" letztlich auch als benutzerfreundlich bezeichnen. Jedenfalls besser als das nicht-haltbare Versprechen "gib irgendwas ein, ich interpretiere das schon irgendwie sinnvoll", was manchmal geht, manchmal falsch interpretiert wird, und manchmal aus für den Nutzer wahrscheinlich nicht nachvollziehbaren Gründen, gar nicht geht.

[Leonidas]

Entscheidet sich Bedienkomfort am Engagement des Entwicklers oder gibt es Grenzsteine, an denen ich mich zu orientieren habe?
BlackJack hat da ja schon Szenarien aufgezeigt, die durchaus nachvollziehbar sind. Nur, sind solche Ecksteine wirklich Grenzsteine? Oder sollte Software hier öfters als man das bisher gewohnt ist die googlesche Frage "Meinten Sie vielleicht..." stellen, wenn Eingaben nicht validiert oder zugeordnet werden können?

Also ich werd immer grantig wenn ich irgendwas mit ``date`` setzen soll, weil das Teil so viele Formate irgendwie versteht, aber nie so wie ich mir das wünsche. Da wär 1 (!) festes Format meiner Meinung nach am besten.

[mutetella]

Eine Office-Suite ist einfach nicht intuitiv bedienbar. Technisch uninteressierte Nutzer sollten nicht erwarten damit einfach so umgehen zu können.

Ich hab' jetzt natürlich kein Bedienkonzept in der Schublade, das eine Office-Suite zum Kindergeburtstag macht. Allerdings finde ich durchaus, dass es möglich sein muss, auch eine Office-Suite intuitiv (was immer das konkret heißen mag) bedienbar zu gestalten. Die Ribbons, mit denen Microsoft beispielsweise versuchte, sich auf den Nutzer zuzubewegen wurden sehr kontrovers diskutiert und waren vielleicht ein Griff ins Klo. Trotzdem war das ein Versuch, der grundsätzlich in eine richtige Richtung weist. Sind WYSIWYG, der Rechtsklick, Drag & Drop und undurchsichtige Formelgeneratoren wirklich der Status Quo, ab dem nichts mehr weitergeht? Kann es wirklich nicht gelingen, auch komplexen Funktionsmonstern neue Zugänge für Normalsterbliche zu gewähren?
Muss jemand wie meine Frau wirklich verstehen, weshalb sie sich für eine fortlaufende Seitennummerierung zuerst zu den Seiteneinstellungen durchklicken muss, um danach noch über 'Einfügen -> Feldbefehl' die Seitennummer zu erhalten?

...weil sie sich nicht mit den Konzepten, die hinter einer Textverarbeitung stehen, auseinander setzen können oder wollen.

Zu allererst: Ich gebe Dir Recht. Natürlich muss jeder, der ein Werkzeug benutzen möchte, sich mit dessen Eigenschaften auseinandersetzen. Allerdings ist das nur eine Seite der Medaille. Auf der anderen Seite steht viel zu oft ein Bedienkonzept im weg, das sich nicht mehr am Menschen orientiert, sondern den Benutzer dazu zwingt, der internen Programmlogik zuzuarbeiten. Deshalb findet heute ständig statt, was Du so treffend ausgedrückt hast:

... "gegen" die Software arbeiten ...

Zurück zum Eigentlichen...

... aber je mehr Freiheit man dem Benutzer lässt, um so mehr Code zum parsen und validieren benötigt man, der eine Fehlerquelle darstellt und immer weiter gepflegt werden muss. Um so mehr Dokumentation benötigt man, die dem Benutzer erklärt was er eingeben kann und was nicht. Desto mehr Mehrdeutigkeiten können sich an solchen Stellen einschleichen. ...

Schon richtig. Wenn das der Preis ist, stellt sich doch nur die Frage, ob der Entwickler im Einzelnen bereit ist, diesen Preis zu zahlen.

Um wieder auf die Tiefebene meines popeligen Kalenders zu kommen: Was spricht außer dem Aufwand noch gegen folgende möglichen Aufrufe an einem 12.05.2011 um 13.34 Uhr, wenn in der Konfiguration festgelegt wurde,

• dass einer datetime-Eingabe grundsätzlich das Format '%Y.%m.%d %H.%M' zugrunde liegen muss,
• die Standardlänge für einen Termin 1 Stunde beträgt und
• der Grundsatz 'date vor time' gilt

(ich hatte nie behauptet, dass eine Eingabe völlig grenzenlos sein sollte ):

Code: Alles auswählen

denkdran -b 12.05.2011 16.30
denkdran -b 0 16.30
denkdran -b 12.05. 16.30
-> 12.05.2011 von 16.30 - 17.30 Uhr
denkdran -b 13.
denkdran -b +1
-> 13.05.2011 von 13.00 - 14.00 Uhr
denkdran -b +2 15. -e +2 16.
-> 14.05.2011 von 15.00 - 16.00 Uhr
denkdran -b 15. 16.
-> 15.05.2001 von 16.00 - 17.00 Uhr

Jetzt ließe sich natürlich einwenden, dass eine Eingabe von 'denkdran -b +2 15. -e +2 16.' ebenfalls ein unbedingtes Auseinandersetzen mit dem Eingabekonzept voraussetzt. Würde meine Frau sicher nicht machen. Muss sie aber auch nicht. Sie kann ja ihre Schreibweise 'denkdran -b 14.05.2011 15:00 -e 14.05.2011 16:00' verwenden. Ich wiederum würde die verkürzte Schreibweise vorziehen.

Bin gespannt, wie ihr das seht...

mutetella

[Leonidas]

Also gerade für solche Sachen würde man Ottonormalusern GUI-Interfaces vorsetzen, die ihre Eingaben in einer festen Form entgegennehmen. Ich würde jetzt meinen Eltern nicht erzählen wie sie Programme in der Kommandozeile aufrufen sollen, sondern ihnen eine Oberfläche geben, aus der siche mit try&error so grob die Funktionsweise des Programms steuern können.

[mutetella]

@Leonidas:
Und Du? Würdest Du Programmaufrufe, wie ich sie als Beispiele aufgeführt habe, verwenden? Oder findest Du sowas eher sinnfrei? Denkst Du, dass Leute, die Vim verwenden und ihre Maus im Schrank verräumt haben einen solchen Komfort nicht schätzen (ernst gemeinte Frage!)?

[Leonidas]

Nein. Denn Vim verwende ich grob täglich mehrere Stunden, relativ intensiv obwohl ich mir natürlich auch nur einen Bruchteil seiner Optionen überhaupt merken kann. Wenn ich ein anderes Programm mit so einem komplexen UI nutzen müsste, dann würde ich nur die Optionen nutzen die ich mir einprägen kann oder kurz aus der ``--help`` rauslesen kann. Und in letzterer schaue ich meist nach Optionen die ich suche, eigentlich nie im Sinne von "welche Optionen gibt es denn, wie kann ich das Programm effizienter nutzen". Natürlich ist es lockend das Program auf arkane Weise unfassbar konfigurierbar zu machen, aber dann kommt sowas wie Vim oder Git raus und ob man das als Richtlinie nehmen will, wie Programme mit dem User interagieren?

Kleines Beispiel: einige Leute wissen nicht dass GNU tar inzwischen ziemlich gut mit Archivformaten umgehen kann, so das man zum entpacken von ``bz2`` eigentlich nie die ``j``-Option hernehmen muss -- tar erkennt selbst dass es ein bzip2-komprimiertes Archiv ist. Wenn man das nicht weiß, schaut man aber auch eigentlich nie in die Dokumentation um das herauszufinden, sondern machts einfach so wie man es weiß.

Was ich aber durchaus nützlich finde sind so Hints wie glaub ich Emacs und Git geben. Letzteres sagt etwa in ``git status`` was man machen muss um Dateien hinzuzufügen und sie wieder zu revertieren. Und mir scheint an zunehmend mehr Stellen.