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.
$ programm --command name=value othername=othervalue
Sollte ein übergebener Name nach '--command' nicht gültig sein, möchte ich einen 'ArgumentError' werfen. Ein 'AttributeError' wäre wohl auch nicht wirklich unpassend, allerdings finde ich, dass auf der Kommandozeile keine Attribute sondern Argumente übergeben werden.
Mich würde jetzt interessieren, ...
... weshalb 'ArgumentError' keine built-in exception ist, 'AttributeError' aber schon?
... ob ihr für diesen Fall einen 'ArgumentError' extra definieren oder einen 'AttributeError' verwenden würdet?
mutetella
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
Warum sollte ArgumentError überhaupt ein built-in sein? Ich könnte mir jetzt diverse Fehler einfallen lassen, welche alle nicht von built-ins abgedeckt sind. Am besten schaust du mal in die Dokumentation und überlegst, welche Basis am besten für deine Exception geeignet ist und erbst davon. In diesem Fall würde ich mich an Exception halten.
Alternativ kannst du auch über das argparse-Modul gehen. Gibt es eigentlich einen Grund, warum du deinen eigenen Parser schreibst und nicht eines der vorhandenen Module verwendest?
Zuletzt geändert von EyDu am Sonntag 30. Dezember 2012, 19:39, insgesamt 1-mal geändert.
@mutetella: Python hat Objekte und die haben Attribute und man kann auf Attribute zugreifen die nicht existieren, beziehungsweise so einen Zugriff versuchen. Was sollte in dem Fall denn passieren wenn `AttributeError` nicht zu den eingebauten Ausnahmen gehören würde? Jedes nicht absolut triviale Programm verwendet auf die eine oder andere Weise Attributzugriffe.
Dagegen ist das Parsen von Kommandozeilenargumenten nur für einen Bruchteil von Programmen interessant. Und dafür gibt es weder einen eingebauten Parser noch sind die Argumente selbst ohne einen Import erreichbar. Das wäre doch komisch wenn man einen `ArgumentError` auslösen könnte ohne das man überhaupt an die Argumente selbst heran kommt.
So einen Ausnahmetyp würde ich in dem Modul suchen welches zum Parsen verwendet wird. `argparse.ArgumentError` existiert schliesslich. Oder noch besser: Man nimmt eine andere Ausnahme die besser ausdrückt *was* an dem Argument falsch ist. Dafür kommen üblicherweise `TypeError` oder `ValueError` in Frage. Im Beispiel letzteres wenn der Name ein falscher Wert ist.
Letztlich würde ich dem Benutzer in so einem Fall aber auch kein Ausnahme präsentieren, denn der Stapelabzug ergibt keinen Mehrwert. Module zum Parsen von Kommandozeilenargumenten haben oft auch etwas für Fehler. Die Parser von `optparse` und `argparse` haben dafür zum Beispiel eine Methode.
Edit: Ist mir beim nochmaligen Lesen aufgefallen: Warum zum Henker erfindest Du das Rad noch mal neu wenn es in der Standardbibliothek doch schon etwas zum Parsen der Kommandozeilenargumente gibt‽
Nun ja, vielleicht ist parsen auch ein wenig dick aufgetragen. Natürlich verwende ich 'argparse'. In meinem Beispiel bekomme ich für das '--command' Argument von 'argparse' den Wert ['name=value', 'othername=othervalue']. Und aus diesem Wert macht mir mein Parser dann ein {'name': value, 'othername': othervalue} und prüft dabei ein paar Sachen wie eben die Gültigkeit eines Namens (wobei ich inzwischen überlege, ob das überhaupt da reingehört) oder die richtige Syntax der Zuordnung.
'argparse.ArgumentError' ist ein guter Vorschlag, danke!
mutetella
@BlackJack: Passt jetzt überhaupt nicht zum Thema, wollte ich Dich aber schon des öfteren Fragen: Weshalb schauen die ? in Deinen Beiträgen ‽ <- so aus?
Entspanne dich und wisse, dass es Zeit für alles gibt. (YogiTea Teebeutel Weisheit )
@BlackJack: Und nutzt du zum Einbringen dieser Zeichen in deine Beiträge den manuellen Weg durch Kopieren aus einer Zeichentabelle oder gibt es dafür ein Browser-Plugin?
@snafu: Weder noch — dafür gibt es wie in dem Artikel beschrieben die Compose-Taste unter Linux. Das ist bei mir die rechte Tux-Taste. (Gerüchteweise soll es ein paar Tastaturen geben wo auf dieser Taste statt eines Pinguins ein Windowslogo abgebildet ist ;-)). Nach dem man die betätigt hat, gibt es Tastenfolgen von zwei bis drei Tasten, die zu Zeichen führen. In der Regel recht intuitiv in dem verschiedene Zeichen die auf der Tastatur abgebildet sind zu neuen ”zusammengesetzt” werden —deswegen wohl auch die Bezeichnung Compose-Taste. Beispiele: "a → ä, ss → ß, ,c → ç, !? → ‽, ... → …, ** → ★, *a → α, *b → β, *d → δ, *l → λ, '' → ”, ,, → „, >> → », << → «, != → ≠, >= → ≥, <= → ≤, xx → ×, +- → ±, in → ∈, !in → ∉, |N → ℕ, |Z → ℤ, AA → ∀, EE → ∃, \/ → ∨, /\ → ∧, :) → ☺, :( → ☹, <3 → ♥, ae → æ, oe → œ
Klappt bei mir nicht. Entweder bin ich zu blöd oder mein System ist andes eingestellt. Bin hier mit Linux Mint unter Cinnamon unterwegs. Standardmäßig war eingestellt, dass die Windowstaste das Menü aus der Taskleiste aufmacht. Diesen Shortcut habe ich rausgenommen, aber noch immer führt die Eingabe "Windowstaste + ss" nicht zu "ß". Habe sowohl die Windowstaste gedrückt gehalten und zusätzlich "ss" eingegeben, als auch zuerst die Windowstaste gedrückt und wieder losgelassen und dann "ss" eingegeben. Beim Gedrückthalten der Windowstaste und zusätzlich "ss" - also Variante 1 - tut sich rein gar nichts (auch nicht nach dem Loslassen der Windowstaste). Bei Variante 2 (erst drücken und loslassen, dann "ss" eingeben), schreibt er ganz normal das "ss" hin.
EDIT: Hat sich erledigt. Der Compose-Key war gar nicht belegt. Lässt sich ändern mittels Start → Einstellungen → Tasten → Belegungen → Optionen → Position der Compose-Taste.
)
