Vereinfachtes "Typechecking" möglich?

[CM]

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.

Oh, jaaa
Aber bisher ist die in Frage kommende Funktion die Einzige, die zu diesen rel. low-level-Zugriff ermuntert. ... Prinzipiell aber hast Du recht: Auch das sollte ich überdenken. Danke.

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

Berechtigter Einwand, aber meine pot. Nutzer sind Wissenschaftler, die alle glauben programmieren zu können und ungerne Doku lesen ... (die Doku erstelle ich gerade erst )

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.

meine Antwort

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.

Anstelle von "eine Funktion" sollte es wohl "eine bestimmte Funktion" lauten. Aber die Diskussion und meine Antworten leiten mich zum Gedanken, daß ich auch an der Stelle das Design überdenken sollte ...

Auweia, hätte ich gewußt, daß ich sooo eine Diskussion losschiebe ... ist aber eigentlich ganz interessant.

Gruß,
Christian

[birkenfeld]

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

Berechtigter Einwand, aber meine pot. Nutzer sind Wissenschaftler, die alle glauben programmieren zu können und ungerne Doku lesen ... (die Doku erstelle ich gerade erst )
[/quote]

In dem Fall wäre aber auch eine saubere Lösung z.B. mit Dekoratoren gut:

Code: Alles auswählen

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

Das hat den Vorteil, dass sich der Overhead fürs Typen prüfen trivial abschalten lässt, indem man nur `takes` umdefiniert.

[CM]

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

Gruß,
Christian

[birkenfeld]

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

Da muss man sich halt entsprechende Notationen einfallen lassen.

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

Es wird sie weiterhin in der gewohnten Form geben, zusätzlich auch als Klassendekoratoren.