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.
naja, es heißt mache etwas "mit" einem objekt...
das kann schon sehr praktisch sein...z.b. wenn man wie in VBA objekte,z.B. diagramme, umfangreich konfigurieren muss.
wenn du bei so nem excel diagramm codetechnisch alle möglichkeiten ausschöpfen willst, dann spart das schon viel zeit.
@LiLaLaunebär: In wiefern spart das Zeit? Also gegenüber der Lösung dem Objekt einen kurzen Namen zu verpassen!?
@problembär: Das ``with`` in Python macht semantisch etwas ganz anderes als das ``with`` in verschiedenen BASIC-Dialekten oder Pascal. Während man das "BASIC"-``with`` einfach durch einen kurzen temporären Namen "simulieren" kann, macht ein Kontextmanager deutlich mehr als einfach nur eine Art impliziten Namen zu vergeben.
naja, du hast ein excel sheet mit sagen wir 10 diagrammen...ist ja keine seltenheit.
so, jetzt schreibst du das skript zum erzeugend es sheets ja nicht nur für dich alleine, sondern es wollen vllt auch andere leute in deinem unternehmen weiterentwickeln, also scheiden x,y und z als Variablenname aus...
eine sinnvolle bezeichnung, wie wir sie der verständlichkeithalber benutzen, wäre dann DiaMarketShare,DiaRevenue etc...oder jedes davon hat 10-15 konfigurationsmöglichkeiten (Höhe,Breite,Position,Farbe,Hintergrund,Linienart,Diagrammart,Farben...) diese können auch noch verschachtelt sein...da kommt ganz schön was zusammen. ich sehe with da schon als vorteil
neben der schreibersparnins erhöht das aus meiner sicht auch die lesbarkeit, da dadurch eine gewisse struktur hinein kommt.
aber nun gut, die geschmäcker sind verschieden, das hat auch der affe gesagt, als er in die seife gebissen hat
LiLaLaunebär hat geschrieben:eine sinnvolle bezeichnung, wie wir sie der verständlichkeithalber benutzen, wäre dann DiaMarketShare,DiaRevenue etc...oder jedes davon hat 10-15 konfigurationsmöglichkeiten (Höhe,Breite,Position,Farbe,Hintergrund,Linienart,Diagrammart,Farben...) diese können auch noch verschachtelt sein...da kommt ganz schön was zusammen. ich sehe with da schon als vorteil
neben der schreibersparnins erhöht das aus meiner sicht auch die lesbarkeit, da dadurch eine gewisse struktur hinein kommt.
Diese Struktur erziehlt man in Python z.B. durch Funktionen und innerhalb dieser Funktion kann man dann auch einen kurzen Namen wie `dia` verwenden. (Das ist natürlich nur eine Möglichkeit von vielen.)
„Lieber von den Richtigen kritisiert als von den Falschen gelobt werden.“
Gerhard Kocher
LiLaLaunebär hat geschrieben:eine sinnvolle bezeichnung, wie wir sie der verständlichkeithalber benutzen, wäre dann DiaMarketShare,DiaRevenue etc...oder jedes davon hat 10-15 konfigurationsmöglichkeiten (Höhe,Breite,Position,Farbe,Hintergrund,Linienart,Diagrammart,Farben...) diese können auch noch verschachtelt sein...da kommt ganz schön was zusammen. ich sehe with da schon als vorteil
neben der schreibersparnins erhöht das aus meiner sicht auch die lesbarkeit, da dadurch eine gewisse struktur hinein kommt.
Der „Python-Weg“ wäre wohl, ein Dictionary zu nehmen(oder __init__ gleich entsprechend entwerfen):
def setup(obj, **dict_):
for name, value in dict_.iteritems(): setattr(obj, name, value)
return obj
setup(a, val1=1, val2=2, val2=3)
Für Funktionsaufrufe könnte man sich ähnliches basteln.
Recht elegant ist das bei Smalltalk gelöst, wo man Nachrichten per „;“ verketten und damit nacheinander an das selbe Objekt senden kann.
Die lokalen Funktionen können ruhig alle gleich heißen.
Ein `with` ist nicht nötig. Die Existenz von `with` in JavaScript ist übrigens ein Hauptgrund für schlechte Performance. Daher wird das bei ECMAScript 5 "strict" auch entfernt. Python sollte es also nicht übernehmen. (Das `with` von Python als Abkürzung für `try/finally` ist übrigens etwas ganz anderes).
Das "with" von VB/VBA hatte übrigens auch sehr unangenehme Seiteneffekte, wenn man den "with-Block" zwischendrin verließ, soviel ich mich erinnere.
Das "with" von Python dagegen ist eine super Erfindung.
BlackJack hat geschrieben:@problembär: Das ``with`` in Python macht semantisch etwas ganz anderes als das ``with`` in verschiedenen BASIC-Dialekten oder Pascal. Während man das "BASIC"-``with`` einfach durch einen kurzen temporären Namen "simulieren" kann, macht ein Kontextmanager deutlich mehr als einfach nur eine Art impliziten Namen zu vergeben.
mkesper hat geschrieben:Das "with" von VB/VBA hatte übrigens auch sehr unangenehme Seiteneffekte, ...
Das "with" von Python dagegen ist eine super Erfindung.
Paßt doch zu meiner These: Das "with" sagt zu wenig aus, man muß zuviel hineininterpretieren, dann gibt es "with im Sinne von Basic", "with im Sinne von VBA", "with im Sinne von Perl", "with im Sinne von Python", und jedes macht was anderes.
Ich kann nicht mal nach "Perl with" bei Google suchen, weil "with" eben überall vorkommt.
Wie gesagt, ich find's in Programmiersprachen nicht gut (und benutze es nicht).
problembär hat geschrieben:Paßt doch zu meiner These: Das "with" sagt zu wenig aus, man muß zuviel hineininterpretieren, dann gibt es "with im Sinne von Basic", "with im Sinne von VBA", "with im Sinne von Perl", "with im Sinne von Python", und jedes macht was anderes.
Ich kann nicht mal nach "Perl with" bei Google suchen, weil "with" eben überall vorkommt.
Wie gesagt, ich find's in Programmiersprachen nicht gut (und benutze es nicht).
Um es mal zu überspitzen: Du forderst also eine einzige Programmiersprache damit man nichts verwechseln kann?
Verwechslungsgefahr von Elementen einer Sprache mit einer anderen Sprache ist kein echtes Argument. Wenn du eine Sprache verwendest, dann bewegst du dich in dessen Kontext und daraus ergibt sich die Bedeutung von Statements. Wenn du Dinge verwechselts dann beherrscht du mindestens eine Sprache davon nicht richtig. Es kann sicher nicht das Ziel sein Sprachen so einfach zu entwerfen, dass man sie auf Anhieb kann und alles richtig macht.
Und zu Behaupten, dass etwas nicht sinnvoll sei, weil es nicht mit Google gefunden werden kann, grenzt schon an Lächerlichkeit. Zu Programmiersprachen existieren Dokumentationen und wenn man etwas sucht, dann kann man darin nachlesen.
@problembär: Diese Argumentation trifft aber auch mindestens auf ``and``, ``as``, ``else``, ``for``, ``global``, ``import``, ``in``, ``or``, und ``yield`` zu. Die gibt es alle auch in anderen Programmiersprachen mit von Python abweichender Semantik. Soll man da jetzt deswegen drauf verzichten? Also mal von ``global`` abgesehen, denke ich das man das nicht sollte.
Das fängt doch schon bei so grundlegenden Sachen wie ``for``-Schleifen an. Python's ``for`` ist keine Zählschleife wie in vielen anderen Programmiersprachen, sondern eine ``foreach``-Schleife -- wie das Schlüsselwort für die Python-Semantik in einigen dieser Sprachen heisst, die sie neben der Zählschleife ebenfalls anbieten.
``as`` wird in Python zum Binden von alternativen Namen an Objekte verwendet, in anderen Sprachen zum Deklarieren von Datentypen.
``and``/``or`` haben nicht in allen Sprachen den gleichen Operatorvorrang wie in Python und ob eine Kurzschlussauswertung gemacht wird, oder grundsätzlich der gesamte Ausdruck ausgewertet wird, ist auch nicht bei jeder Sprache gleich geregelt.
Man muss letztendlich immer zu den Schlüsselwörtern die Bedeutung in der konkreten Programmiersprache dazulernen. Sonst kann man böse Überraschungen erleben und versteht nicht warum das Programm nicht das tut was man haben wollte. Mit einem "ach das ist ja aus dem Wort schon klar was das bedeutet" fällt man früher oder später auf die Nase.
In "lebenden" Sprachen wird sowas oft als "false friend" bezeichnet. Sich darauf zu verlassen, daß Wörter, die ähnlich klingen aufgrund der oftmals ja durchaus gegebenen engen Sprachverwandtschaft auch tatsächlich die gleiche Bedeutung haben, ist zwar bequem und menschlich, aber eben bisweilen auch tückisch. Trotzdem kannst du nicht auf solche Wörter verzichten, ohne deinen Wortschatz bzw. die Sprache an sich um ein Gutteil ärmer zu machen.
EyDu hat geschrieben:Um es mal zu überspitzen: Du forderst also eine einzige Programmiersprache damit man nichts verwechseln kann?
Quatsch. Er fordert Programmiersprachen mit Keywords und Konzepten die etwa so benannt sind: fdsjf, ackh, ghrig342fs, dfsocx8ds5a und natürlich nicht zu vergessen 323sadawecv78ds. Man muss jedoch aufpassen, dass diese wirklich Sprachspezifisch sind - Dialekte der Ursprungssprache müssen die die Namen ändern, da sie in der Zukunft divergieren könnten.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice