Das deutsche Python-Forum

CM hat geschrieben:Meine Frage: Gibt es für dieses Konstrukt auch eine Abkürzung? Es sieht so unschön aus ...

assert isinstance(move, dict),'move is no dictionary'

CM hat geschrieben:Gibt es für dieses Konstrukt auch eine Abkürzung?

if move:
    try:
        for chain, params in move.iteritems():
            try:
                for param, value in params.iteritems():
                    value = float(value)
                    # ...
                    # ...
            except AttributeError:
                raise AssertionError("entry for chain %s is no dictionary" % chain)
            except ValueError:
                raise AssertionError(
                    "entry for %s in chain %s is not number (float or int)" %
                    (param, chain)
                )
    except AttributeError:
        raise AssertionError(
            "given parameter 'move' is no dictionary, see documentation for "
            "further details"
        )

lutz.horn hat geschrieben:Der Nachteil dabei ist natürlich, dass nicht die anwendungsspezifischen Fehlertexte ausgegeben werden.

helduel hat geschrieben:

Code: Alles auswählen

assert isinstance(move, dict),'move is no dictionary'

So umgehst du das ganze if/raise-Zeugs.

helduel hat geschrieben:Ansonsten kann ich auch nur empfehlen, nicht alles überprüfen zu wollen.

EyDu hat geschrieben:"assert" ist nur zum Testen gedacht und nicht zum Implementieren von Logik, da beispielsweise bei Erzeugung von optimiertem Code alle assert-Statements entfernt werden.

Zap hat geschrieben:Wo kann man mehr über diese Verhaltensweise erfahren?!
Von welcher Optimierung redest du? Gibt's automatisierte Optimierungen die das in der Realität machen?[/qoute]
Lies dir hier dazu einfach mal den letzen Absatz durch.

Zap hat geschrieben:Ich bin hier und da durchaus geneigt asserts einzubauen
sollte man stattdessen lieber "if foo: raise MyException("bar") " verwenden?

CM hat geschrieben: Sorry, aber hier muß ich noch mal Stellung nehmen: Das mache ich doch, da - wie beschrieben - es sich um eine an einen pot. Nutzer einer Applikation gerichtete Eingabefunktion handelt.

CM hat geschrieben:

helduel hat geschrieben:Ansonsten kann ich auch nur empfehlen, nicht alles überprüfen zu wollen.

[...]
DAS zeugt ggf. von schlechtem Design. Insbesondere, wenn es sich um rechenintensive Software handelt, wo der Traceback dann im Zweifelsfall erst nach geraumer Zeit kommt - insofern muß ich auch noch mal darüber nachdenken, ob ich Gerolds Lösung tatsächlich so gut für mich finde. (Wußte doch, daß ich mir was dabei gedacht hatte nicht mit try/except zu arbeiten ... gehört unbedingt als Kommentar rein, wenn ich mich gegen Gerolds Version entscheide.)
[...]
Zu dem "assert" sage ich jetzt mal nichts - wie ich sehe hat das zwischenzeitlich schon ein Anderer getan ...

EyDu hat geschrieben: Lies dir hier dazu einfach mal den letzen Absatz durch.

birkenfeld hat geschrieben:Warum verlinkst du gegen die Doku zu 1.5.2?

BlackJack hat geschrieben:Vielleicht könntest Du das von der Funktion trennen und eine Extrafunktion zum überprüfen der Benutzereingabe einfügen. Benutzereingaben muss man natürlich so gut wie möglich überprüfen, man ahnt ja meist gar nicht auf was für Ideen die so kommen können.

birkenfeld hat geschrieben:Wenn der Nutzer falsche *Typen* (nicht Werte) übergeben kann, ist er Programmierer, denn dann hat er Code geschrieben, der mit deinem interagiert. Dann aber kann man zumindest verlangen, dass er die Dokumentation liest (die wiederum hoffentlich für öffentliche Schnittstellen existiert).

helduel hat geschrieben:Ich ging nicht davon aus, dass der User sich darum kümmern soll, dass die Daten irgendwie ordentlich in Dictionaries verpackt daherkommen, sondern dass das deine Applikation macht.

CM hat geschrieben:eigentlich soll meine Applikation von mir was folgt mehr oder weniger automatisch berechnen, aber Nutzer sollen doch auch die Möglichkeit bekommen einen Sack voll Paramter per Hand an eine Funktion zu geben.

birkenfeld hat geschrieben:Wenn der Nutzer falsche *Typen* (nicht Werte) übergeben kann, ist er Programmierer, denn dann hat er Code geschrieben, der mit deinem interagiert. Dann aber kann man zumindest verlangen, dass er die Dokumentation liest (die wiederum hoffentlich für öffentliche Schnittstellen existiert).

@takes(str, dict)
def foo(...)

CM hat geschrieben:Das ist in der Tat eine interessante Option, aber ich muß zugeben: Hier stoßen meine Pythonfähigkeiten seit langem wieder an eine Grenze. Wie müßte denn takes aussehen, wenn

Code: Alles auswählen

def foo(self, par0, par1=default_integer, par2=default_list, par3=verschachteltes_default_dict):

mit par0 einem x-beliebigen Argument entsprechend, z. B. ein String (weil der in der Auflistung fehlt ).

Außerdem, und hier wird es wichtig, wie sieht es mit Dekoratoren in Python 3k aus? Ich habe gesucht und nichts gefunden, vermute aber, daß ich bloß zu blöd zum finden war ...