x parametre

[BlackJack]

@Hyperion: Ist das hauptsächlich nervige bei Java nicht, dass es weder `Map`-Literale noch die Möglichkeit gibt ein `Map`-Exemplar wie `dict()` mit Schlüsselwort-Argumenten zu füllen? Das werden in Java dann ja erst mal richtig viele Quelltextzeilen für etwas was eigentlich ganz einfach ist, oder zumindest sein sollte.

Bei der Signatur von `dict()` kann ich mich übrigens auch an Diskussionen in der englishsprachigen Newsgroup erinnern, dass es blöd ist, dass man sich dadurch Möglichkeiten verbaut hat, wie zum Beispiel ``dict(capacity=100)`` um die Hashtabelle beim Erstellen auf eine bestimmte Grösse vorzuinitialisieren, oder in Anlehnung an das `key`-Argument bei `list.sort()`/`sorted()`/`min()` usw. eine andere Funktion anzugeben als `hash()` um den Schlüssel in die Hashtabelle einzutragen.

[Hyperion]

@Hyperion: Ist das hauptsächlich nervige bei Java nicht, dass es weder `Map`-Literale noch die Möglichkeit gibt ein `Map`-Exemplar wie `dict()` mit Schlüsselwort-Argumenten zu füllen?

Stimmt! Ginge das, wäre es auch in Java in solchen Fällen erträglich(er). Ok, dank Eclipse und Co. tippern sich solche Snippets auch relativ fix, dennoch ist es ziemliche viel Boilerplate.

Bei der Signatur von `dict()` kann ich mich übrigens auch an Diskussionen in der englishsprachigen Newsgroup erinnern, dass es blöd ist, dass man sich dadurch Möglichkeiten verbaut hat, wie zum Beispiel ``dict(capacity=100)`` um die Hashtabelle beim Erstellen auf eine bestimmte Grösse vorzuinitialisieren, oder in Anlehnung an das `key`-Argument bei `list.sort()`/`sorted()`/`min()` usw. eine andere Funktion anzugeben als `hash()` um den Schlüssel in die Hashtabelle einzutragen.

Stimmt. An solche Dinge denkt man irgend wie selten - bis es einen "trifft". Andererseits fällt mir nicht ein, wie man das sonst lösen könnte / sollte? Manchmal ist der hauptsächliche use-case imho wichtiger, als alle Eventualitäten abzudecken.

[lunar]

@BlackJack: Es ist Dir bestimmt nicht entgangen, dass auch die von Dir gezeigte Alternative, die in der Tat nicht wesentlich mehr Tipparbeit darstellt, nur deswegen funktioniert, weil auch die Signatur von "dict()" dank **-Magie beliebig viele Schlüsselwortargumente akzeptiert. Ich bedauere, Dir zu widersprechen, doch es fällt mir angesichts dieses Umstandes schwer, Dein Dogma zu verstehen.

Ich will bestimmt nicht abstreiten, dass die Asterik-Formen in der Signatur der Lesbarkeit des Quelltexts durchaus abträglich sein können, und den Gebrauch anderer Namen in der Signatur erschweren oder gar verhindern, doch in Fällen, in denen diese Formen der Lesbarkeit zuträglich sind, ist ihrer Anwendung meines Erachtens durchaus zu begrüßen. Der diskutierte Fall der ".render()"-Methoden für Template-Objekte fällt nun genau in diese Kategorie.

Im Übrigen stellt die Signatur dieser Methoden in den üblichen Template-Engines nun mittlerweile ein mehr oder weniger unveränderliches Faktum dar, so dass die Diskussion über Sinn und Unsinn dieses speziellen Falls mir reichlich überflüssig erscheint.

[BlackJack]

@lunar: Nein das ist mir nicht entgangen -- warum das auch bei `dict()` schlecht ist, habe ich aber auch schon geschrieben. Nur kann ich die Signatur von `dict()` nicht mehr ändern -- da ist die API nun mal vergeigt worden -- aber ich kann sehr wohl in meinem Quelltext nicht den gleichen Fehler machen.

[Hyperion]

Mir ist in dem Zusammenhang noch ein schönes Beispiel eingefallen: die format()-Methode von Strings! Auch da ließe sich die Argumentation der dict()-Befürworter anwenden, oder irre ich hier?

[lunar]

@BlackJack: Nun, offenbar hindert Dich dennoch nichts daran, von der „vergeigten API“ zu profitieren, in dem Du diese in Deinem Quelltext verwendest. Gäbe es diese API nicht, dann bleibe nur an dieser Stelle doch eher unschöne Literalform.

Die Nachteile habe ich im Übrigen nicht in Abrede gestellt, doch bezweifele ich deren Auswirkungen. Ich sah mich nie in der Situation, benutzerdefinierte Hash-Funktionen zu nutzen, in Python nicht, und auch nicht in C++, wo dies bei den meisten Bibliotheken, die ungeordnete Mengen und Wörterbücher bieten (insbesondere Boost oder C++0x) möglich ist.

[BlackJack]

@lunar: Was sollte mich denn daran hindern? Dir ist der Unterschied zwischen etwas benutzen was schon da ist, und das man nicht ändern kann, und dem Entwurf eigener APIs schon klar!? Und ich würde auch die Literalform vorziehen wenn die `dict()`-Signatur anders aussehen würde.

Schön dass Du über solche Probleme noch nicht gestolpert bist -- Leser der Python-Newsgroup halt schon und ich persönlich auch schon. Dementsprechend bezweifle ich die Auswirkungen nicht. Man muss sich halt klar darüber sein, dass man die API bei so einer Signatur in Stein meisselt und nicht mehr problemlos erweitern/ändern kann, und wenn man keine Namenskollisionen haben möchte, wirklich *nur* ``*args`` und ``**kwargs`` verwenden kann, und kein anderes, weiteres Argument. Und das Python-Schlüsselworte auch dann noch problematisch sind.

[lunar]

@BlackJack: Du „würdest, wenn die "dict()"-Signatur anders aussehen würde“?! Nun sieht die "dict()"-Signatur aber nicht anders aus, und offenbar ziehst Du sie nun, da sie existiert, doch der Literalform vor. Ich erlaube mir, daraus zu schließen, dass Du diese Signatur der Lesbarkeit des Quelltexts für zuträglicher hältst als die Literalform, und dies nun ist genau mein Punkt: Wenn die Anwendung der **kwargs-Magie den Quelltext lesbarer werden lässt, habe ich nichts dagegen, vor allem nicht in so dogmatischer Art und Weise.

Um auf das diskutierte Beispiel der "Template.render()"-Methode zurückzukommen: Hier ist diese Syntax lesbarer als die Literalform, teilweise, weil die eigentlich redundanten Klammern entfallen und die Zeichenkettenliterale implizit sind, vor allem aber, weil sie dokumentiert, dass an dieser Stelle tatsächlich nur bestimmte Schlüssel erlaubt sind. Schließlich unterliegen Bezeichner in der Template-Sprache nahezu denselben syntaktischen Regeln wie in Python (zumindest in Mako und Jinja). Es ist also im Gegensatz zur Literalform deutlich, dass diese Schlüssel keine Daten sind, wie DasIch suggerieren wollte, sondern eben Bezeichner, nichts anderes eigentlich als Namen in einem Python-Programm.

Ich finde, dass dieser Vorteil deutlich wichtiger ist als die in diesem Fall wirklich sehr entfernte Möglichkeit, dass unbedingt ein zusätzliches Schlüsselwortargument zur Signatur hinzukommen müsste, ohne dass es eine andere sinnvolle Alternative gäbe.

[Hyperion]

@BlackJack: Du „würdest, wenn die "dict()"-Signatur anders aussehen würde“?! Nun sieht die "dict()"-Signatur aber nicht anders aus, und offenbar ziehst Du sie nun, da sie existiert, doch der Literalform vor.

In jinja2 verwendet Mitsuhiko übrigens tatsächlich die Literalform bei der Dokumentation der render()-Methode:
http://dev.pocoo.org/hg/jinja2-main/fil ... nt.py#l882

[Xynon1]

Kann das hier einer mal zusammenfassen ?

Denn als jemand der sich noch nie damit befasst hat ist es nicht ganz einfach euch zu folgen.
Also wann ist den nun wann besser ?

Da ich meist mit Tkinter arbeite, weiß ich das dort immer beides ermöglicht wird sowohl dict(), als auch **kwargs, denn die Funktionen sehen ja immer so aus:

Code: Alles auswählen

def __init__(self, master=None, cnf={}, **kw):

Aber welche Möglichkeit sollte man hier nutzen ?

[Xynon1]

push

Die Fragen interessieren mich eigentlich immer noch