Python to C Converter

[LanX]

Was ich hauptsächlich störend finde sind die seltsame Syntax zur Definition von Objekten, die dieses eigentlich völlig überflüssige new-Schlüsselwort erfordert.

ja ... das "new" hatte wohl Marketinggründe, wie die umbenennung von in JAVAscript.

Das seltsame this, auf das man sich nicht verlassen kann (var self = this *hust*).

ich kann dir nicht folgen... Beispiel?

Und die umständliche Scoping-Regel, der man zu verdanken hat, dass man vor praktisch jede Variable var schreiben muss.

hä??? ... gibts außer Python eine andere (nichtakademische) Sprache die per default localisiert und wo man explizit "nonlocal"-isiseren muss (wenn man denn kann)?

"var" ist nervig weil es für den ganzen Scope - also auch vorhergehenden Code - gilt.¹
Deswegen bemängelt Crockfords JS-Lint es auch wenn du die var-Deklarationen nicht am Funktionsanfang machst.

Die Zahl der Prototypen ist natürlich auch nur auf einen beschränkt.

Das ist IMHO ein fettes Plus! Ich bevorzuge - schon aus Designgründen - Mixins. Die Nützlichkeit der Mehrfachvererbung ist m.E. ein Mythos.

Und die Möglichkeit ein Programm gescheit in mehrere Dateien aufzuteilen und somit etwas zu strukturieren fehlt auch völlig. Da braucht man dann wieder zusätzliche Software (sprich: Präprozessoren).

Doch Packaging bekommt man schon ohne Präprozessoren hin, aber auch hier gibts leider keine akzeptierte Best Practice.

1) ich bin mir nicht ganz sicher was Python macht, wenn ich eine neue Variable binde ...gleich mal testen...

[BlackJack]

@LanX: Es wird sich wohl auch keine einheitliche Best Practice durchsetzen. Das ist eben der Nachteil bei der Freiheit an der Stelle.

Ich sehe ``nonlocal`` nicht als essentiell wichtig an. Python hat Klassen, man bekommt da also nichts, was man vorher nicht auch relativ einfach ausdrücken konnte. Klassen sind ein wichtiger Bestandteil von Python und nichts exotisches. Wenn man sie braucht, sollte man sie auch verwenden.

Crockford bastelt mit der `Object.create()`-Funktion `clone` aus Io nach. Der Punkt ist, dass man so etwas Kleines aber Essentielles nicht selber machen sollen müsste. Denn Crockford macht das so und nennt das `create`. Der nächste macht das gleiche und nennt es aber anders. Ein dritter macht etwas leicht verschiedenes, nennt es aber auch `create` und pappt es an das globale `Object`. Und dann versuch mal Code von diesen drei Programmieren in einem Programm zu verwenden.

Nichts gegen Freiheit, aber bei solch grundlegenden Dingen sollte von den Sprachentwicklern mindestens ein Weg fertig und ohne Boilerplate funktionierend angeboten werden. Wer was anderes will, soll ja ruhig die Möglichkeit haben. Bei Io kann man sich auch andere Semantiken basteln.

Ich persönlich mag bei JavaScript am liebsten das Idiom was Crockford "functional inheritance" nennt.

[BlackJack]

@LanX: Ich verstehe Deine Anmerkung zum Scope nicht wirklich. Ohne ``var`` sind Variablen in JavaScript *global* und zwar so *richtig* global. Das ist doof weil in 99% der Fälle nicht das was man will. Und dass sich das ``var`` egal wo es steht auf die Funktion und nicht den Block besteht, ist die nächste Überraschung.

Beispiel für's `this` sind Methoden die man rumreicht und die vielleicht irgendwo in anderen Bibliotheken an ein Objekt gebunden werden, weshalb man das `this` selbst vorher in einem Closure "festnageln" muss, weil es sonst bei der Ausführung nicht an das Objekt gebunden ist, von dem die Methode ursprünglich mal kam. Bin ich auch erstmal mit auf die Schnauze gefallen.

Zum Packaging bringt CommonJS ja vielleicht eine Vereinheitlichung.

[sma]

An paar Anmerkungen: Es ist Mythos, dass fehlende statische Typen zwangsläufig langsamere Programme ergeben. Da gibt es ein Paper aus dem Self-Projekt so ca. 1995, das ich aber zu faul bin, jetzt herauszusuchen, welches das Gegenteil zeigt. Dynamisch typisierte Sprachen sind in der Regel langsamer, weil sie ausdrucksstärker als ihre statisch kompilierenden Brüder sind. So bieten die meisten z.B. korrekte Artithmetik ohne Überlauf ins negative, eine automatische Speicherverwaltung oder ein Modell, wo jeder Datentyp gleichartig (als Objekt) behandelt wird. Mehr Features drücken da natürlich auf die mögliche Maximalgeschwindigkeit.

Ein Python-Programm in ein äquivalentes C-Programm zu übersetzen erfordert letztlich, dass in diesem C-Programm ein kompletter Python-Interpreter vorhanden ist, denn z.B. der exec-Befehl müsste ja funktionieren. Man will also in jedem Fall ein Subset von Python in C übersetzen.

Der andere Ansatz wäre, mit dem semantischen Modell von C zu beginnen, dies in eine Python-Syntax einzupacken und dann zu schauen, welche Features, die C nicht bietet aber Python jetzt noch "billig" hinzuzufügen wären.

Der Autor von Galcon ist auch Autor von tinypy und hat dafür einen Python nach C++ Übersetzer gebaut, damit er Spiele wie Galcon (was AFAIK einen Python-Teil hat oder sogar ganz in Python geschrieben ist) in C++ übersetzen und so einfacher für's iPhone entwickeln kann. So weit ich weiß, ist die Calcon-Version für's iPhone dann aber doch direkt in C++ und/oder Objective-C++ geschrieben worden.

Tinypy könnte aber vielleicht auch so schon für embedded Systeme geeignet sein. Aber auch hier gilt: Das ist kein Python gemäß der von GvR erstellten Spezifikation, sondern etwas, das eine ähnliche Syntax hat und mehr oder weniger nahe bei Python gelegen hat.

Ich hatte man angefangen, einen Übersetzer für ein mit Python-Syntax geschriebenes Java-Programm nach Java zu bauen: http://github.com/sma/dython Damit das funktioniert, braucht man jedoch einen guten Typ-Inferenzer und dazu war ich im May nicht motiviert genug. Statt Java könnte man aber genauso gut auch C-Code erzeugen, müsste dann noch einen GC dazu tun (boehmgc) und ein bisschen Laufzeitbibliothek entwickeln. Ich wollte ja einfach dem Duby^W Mirah-Ansatz folgen und ausschließlich das Laufzeitsystem der Zielsprache einsetzen.

Ich würde übrigens so weit gehen und sagen, JavaScript (ECMAScript 5) kann man prinzipiell schneller ausführen als Python, weil es weniger flexibel ist und weniger Konzepte der Implementierung durchscheinen. Als Beleg würde ich die belang mäßigen (um nicht zu sagen enttäuschenden) Erfolge des Unladen Swallow-Projekts anführen gegenüber dem V8-Projekt und das, obwohl die wirklich wussten, was sie tun und alle State-of-the-Art-Techniken kannten.

Des weiteren würde ich eine Lanze für JavaScript brechen wollen und sagen, dass ich die Sprache nett finde und nur empfehlen kann, Vorurteile abzulegen und sich näher damit zu beschäftigen. Immerhin ist es die am weitesten verbreitetste Sprache und sie wird uns noch viele Jahre erhalten bleiben.

Besser als Lisp (was ich als CommonLisp lesen würde) ist IMHO Scheme, was Reinheit und Klarheit der Konzepte angeht. Diese findet man (bis auf Continuations) auch in JavaScript wieder. Dazu kommt das Objektkonzept von Self, welches sich aus Smalltalk weiterentwickelt hat. Objective-C ist übrigens der Versuch, das Objektmodell von Smalltalk über C zu stülpen. War so eine "das kann doch nicht so schwer sein Idee" von Brad Cox, der 1986 Smalltalk sah, aber lieber C machen wollte und die Idee von Software-Komponenten verfolgte. Der größte Fehler war, die Blöcke zu ignorieren. Kaum 25 Jahre später hat Apple ihn dann korrigiert und eigenmächtig in ihre Version von C, C++ und Objective-C das Konzept von Blöcken integriert. Die selben Blöcke von Smalltalk (traditionell keine Closures wie bei Scheme) machen Ruby übrigens zu einer der mächtigsten Sprachen, was DSLs angeht.

Wo war ich? JavaScript! Ich denke, wo heutzutage C der portable Assembler (wer nicht muss, nutzt diese primitive Sprache doch hoffentlich nicht mehr freiwillig einfach nur so) wird in Zukunft JavaScript im Web-Umfeld diese Rolle übernehmen. 2012, wenn es nach Brendan Eich geht, kommt die nächste EcmaScript-Version, die ein paar weitere Probleme von JS beseitigt, etwa die standardmäßig globalen Variablen oder das Fehlen eines "doesNotUnderstand"-Catchalls. Wie auch immer, CoffeeScript ist ein schönes Beispiel für die JS-ist-portabler-Assembler-für-andere-Sprachen Ansatz.

Lua wäre übrigens anstelle von Python eine IMHO sehr schöne Alternative, wenn es um embedded Systems geht. Gibt es auch einen recht fixen JIT dafür.

Übrigens, Closures sind alles, was man braucht, um Objekte zu realisieren. Daher kann man in Scheme so schön als Fingerübung ein OO-System bauen. Andersherum ginge es auch, ist aber deutlich anstrengender. Wer den Schmerz fühlt, den man hat, wenn man in Java funktional programmieren will, weiß, was ich meine.

Und wer mal "verrückte" (im Sinne von genial) funktionale Programmierung in JavaScript sehen will, schaue sich (fab) (die Klammern gehören zum Produktnamen) (http://github.com/jed/fab) an, ein funktionales Webrahmenwerk für JavaScript.

Noch was: Wer Io mag (und damit eigentlich auch Self mögen müsste) schaue sich mal Ola Binis Ioke an. Das ist eine ziemlich interessante (experimentelle) Weiterentwicklung an.

Stefan

[LanX]

1) ich bin mir nicht ganz sicher was Python macht, wenn ich eine neue Variable binde ...gleich mal testen...

Code: Alles auswählen

>>> a="outer"
>>> def test():
...  print a
...  a="inner"
...  print a
...  return
... 
>>> test()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 2, in test
UnboundLocalError: local variable 'a' referenced before assignment

ähnlich wie in JS ... hmpf ...

[BlackJack]

@LanX: Ich sehe da die Vorteile: Es kann nicht passieren dass sich ein und der selbe Name zum Beispiel in einer Schleife in verschiedenen Durchläufen auf verschiedene Sichtbarkeitsbereiche bezieht. Und da der Compiler schon feststellt welche Namen lokal sind, wird schnellerer Code generiert. Lokale Variablen werden nämlich nicht in einem Dictionary gespeichert, sondern in einem Array und im Bytecode werden die lokalen Namen über einen festen Index referenziert.

[LanX]

Ich sehe ``nonlocal`` nicht als essentiell wichtig an. Python hat Klassen, man bekommt da also nichts, was man vorher nicht auch relativ einfach ausdrücken konnte. Klassen sind ein wichtiger Bestandteil von Python und nichts exotisches. Wenn man sie braucht, sollte man sie auch verwenden.

Naja du argumentierst Python habe "richtige" Closures und dann sagste man solle OOP dafür nutzen...

Es gibt halt ein riesiges funktionales Erbe aus der LISPischen ecke, wenn ich jedes Pattern erst halb auf Pythons OOP umschreiben muss, ist das nicht dasselbe wie wenn ich es direkt umsetzen kann. (wie z.B. in "Higher Order Perl" für Perl beschrieben.)

Das mag für dich nicht essentiell sein, mich schränkt es ein.

Und um den Kreis zu schließen JS bietet es vollständig an¹.

Mithilfe von Closures kannste dort die vermissten OOP Features mehr als kompensieren.

Dazu muss man sich auch in Closures wohlfühlen und denken können. Das meinte ich damit, dass ein reiner Python POV dann viele Möglichkeiten in JS übersieht.

1) zugegeben, das Fehlen von echten Blockscopes durch Curlies zwingt einen manchmal diesen Workaround mit anonymen Funktionen zu nutzen, die sofort in-place ausgeführt werden... auch etwas nervig.

[Darii]

Das seltsame this, auf das man sich nicht verlassen kann (var self = this *hust*).

ich kann dir nicht folgen... Beispiel?

Wenn man eine Methode (Funktion) eines Objektes beispielsweise an einen Event-Handler bindet verweist this nicht mehr auf das aktuelle Objekt aus dem diese Methode stammt sondern auf den Kontext des Event-Handlers. http://www.digital-web.com/articles/sco ... avascript/ Deswegen muss man dann das magische this vorher an eine lokale variable binden, um später noch auf das eigene Objekt zugreifen zu können. In Python wird das verhindert weil man auf normalem Wege nur an die „bound method“s rankommt. In anderen Sprachen (Java, C++) ergibt sich die Problematik auch nicht weil man sowieso nicht an den Funktionszeiger einer Methode rankommt ohne sich auf den Kopf zu stellen.

hä??? ... gibts außer Python eine andere (nichtakademische) Sprache die per default localisiert und wo man explizit "nonlocal"-isiseren muss (wenn man denn kann)?

Ja. Java, C ... such dir was aus.

"var" ist nervig weil es für den ganzen Scope - also auch vorhergehenden Code - gilt.¹
Deswegen bemängelt Crockfords JS-Lint es auch wenn du die var-Deklarationen nicht am Funktionsanfang machst.

Wie sollte es denn sonst funktionieren? Erst ein bisschen mit der Globalen Variable a rumspielen, dann lokal machen und irgendwann später wieder zu einer globalen Variable machen. Wenn das nicht unübersichtlich wäre…

Das ist IMHO ein fettes Plus! Ich bevorzuge - schon aus Designgründen - Mixins. Die Nützlichkeit der Mehrfachvererbung ist m.E. ein Mythos.

Sprich, da es dafür in Javascript keine Sprachmittel gibt, denkt sich jeder ein eigenes System aus, um gemeinsames Verhalten in die Prototypen zu kopieren.

[sma]

[Wie sollte es denn sonst funktionieren? Erst ein bisschen mit der Globalen Variable a rumspielen, dann lokal machen und irgendwann später wieder zu einer globalen Variable machen. Wenn das nicht unübersichtlich wäre…

Das ist tatsächlich, wie es bei (korrekter) lexikografischer Bindung funktionieren sollte.

Code: Alles auswählen

a = 1
def f():
  print(a) # dies müsste eigentlich 1 sein, ist in Python aber ein Fehler
  a = 2 # jetzt habe ich eine lokale Variable, die die globale überschattet
  print(a) # dies müsste 2 sein
print(a) # dies ist 1
f() # müsste 1 und 2 ausgeben, bricht aber ab
print(a) # dies ist wieder 1

Vergleiche dazu in Scheme

Code: Alles auswählen

(define a 1)
(define f (lambda ()
  (print a) ; dies ist 1
  (let ((a 2)) 
    (print a)))) ; dies ist 2 (die Klammern machen die Bindung deutlicher)
(print a) ; gibt 1 aus
(f) ; gibt 1 und 2 aus
(print a) ; gibt 1 aus

In Python hat man sich allerdings dafür entschieden, dass eine Zuweisung innerhalb einer Funktion die Variable als lokal in der gesamten Funktion erklärt und komplett eine gleichnamige globale Variable überschattet. Die einzige Möglichkeit, eine lokale Variable zu deklarieren ist ja implizit durch das Zuweisen eines Wertes. In Scheme geschieht es explizit mittels "let" welches auch gleich noch den Gültigskeitsbereich der Variable klar macht. In JavaScript funktioniert es mit "var" ähnlich wie bei Python, mit der Ausnahme, dass der folgende Fall leider nicht klar definiert ist und sich verschiedene JavaScript-Interpreter unterschiedlich verhalten:

Code: Alles auswählen

if (true) {
  function f() { return 1; }
} else {
  function f() { return 2; }
}
f();

Einige sagen hier 1, andere 2. Würde man var f = function(){...} schreiben - was eigentlich gleichbedeutend sein sollte - funktioniert es AFAIK wie erwartet. In der nächsten EcmaScript-Version soll es daher statt (bzw. zusätzlich zu) "var" noch "let" geben (die Monkey-Implementationen haben das schon), welches sich korrekt lexikografisch wie in Scheme verhält.

Stefan

[sma]

hä??? ... gibts außer Python eine andere (nichtakademische) Sprache die per default localisiert und wo man explizit "nonlocal"-isiseren muss (wenn man denn kann)?

Ja. Java, C ... such dir was aus.

Das ist für Java falsch. Die Sprache verhält sich im Gegensatz zu Python so, wie bereits in meinem Scheme-Beispiel gezeigt und wie man's eigentlich erwarten würde. Für C kann ich's nicht sagen und habe keine Lust, das auszuprobieren. Ruby hingegen macht es wie Python und würde in dem folgenden Programm einen NameError liefern:

Code: Alles auswählen

a = 1
def f()
  puts a
  a = 2
  puts a
end
f()

Und das nonlocal ist glaube ich einzigartig. Schachtelt man in Ruby Closures (mit Methoden geht das gar nicht), kann man standardmäßig die freien Variablen auch ändern. Da Java gar keine Closures kennt und auch Methoden nicht schachteln kann, kommt das Problem eigentlich nicht vor. Nimmt man anonyme innere Klassen mit Methoden als Closures für Arme an, zwingt Java einen hier, die freien Variablen extra als unveränderlich zu deklarieren, damit man sie benutzen darf.

In einer früheren Lua-Version gab es IMHO mal die Notwendigkeit, etwas ähnliches wie "nonlocal" zu deklarieren (irgendwas mit upvals oder so), doch das man man schon vor Jahren zugunsten der gewohnten lexikografischen Bindung aufgegeben.

Stefan

[Darii]

hä??? ... gibts außer Python eine andere (nichtakademische) Sprache die per default localisiert und wo man explizit "nonlocal"-isiseren muss (wenn man denn kann)?

Ja. Java, C ... such dir was aus.

Das ist für Java falsch. Die Sprache verhält sich im Gegensatz zu Python so, wie bereits in meinem Scheme-Beispiel gezeigt und wie man's eigentlich erwarten würde.

Ich bezog mich auch nicht auf das nonlocal/whatever sondern auf das Verhalten, dass Variablen immer global sind. In Javascript muss/kann man ja wie in Python Variablen nicht explizit deklarieren (bis global, nonlokal, var). Die Deklaration erfolgt implizit durch Zuweisung. Wenn ich in Javascript eine Variable benutze ist sie automatisch global. Wenn ich in Java eine Variable deklariere ist sie lokal.

Code: Alles auswählen

function x() { foo = 23 }
x();
foo; // -> 23

[sma]

Sprich, da es dafür in Javascript keine Sprachmittel gibt, denkt sich jeder ein eigenes System aus, um gemeinsames Verhalten in die Prototypen zu kopieren.

Die wichtige Erkenntnis aus dem Self-Projekt (vor 20 Jahren) war, dass protoypische Vererbung mittels Delegation ein so mächtiges Sprachkonzept ist, dass man damit alle andere Systeme simulieren kann. Das man sich damit also verschiedene klassenbasierten Vererbungskonzepte selbst bauen kann, spricht IMHO für und nicht gegen die Sprache und die Wahl von Selfs System für JavaScript.

Warum wurde Vererbung überhaupt erfunden? Um Code zu sparen. Es war (und ist) ein reines Implementationsmittel und man sollte (was leider nur wenige Programmiersprachen machen) eine Subtyp-Beziehung strickt von der Vererbung trennen. Einfache Vererbung ist nicht mächtig genug. Mehrfache Vererbung hat aber Probleme, wenn man statische Klassendefinitionen mit statischen Feldern hat, weil nicht klar ist, ob es diese beim "Diamand-Problem" nun mehrfach gibt oder nicht. Außerdem ist die Serialisierung gleichnamiger Methoden nicht trivial. Das simple Verfahren von Python1.x hat sich nicht bewehrt und der von Dylan stammende Algorithmus (AFAIK der einzige der bislang gefunden wurde, der sich in der Praxis bewährt) wurde erst relativ spät entdeckt und ist auch nicht gerade einfach zu verstehen. Zudem hätte es nicht "super" wie bei Smalltalk heißen dürfen, sondern besser etwas wie "next" oder "call-next-method" wie bei CommonLisp und Dylan, was klar macht, dass hier die nächste weniger spezielle Methode aufgerufen werden soll, die nicht notwendigerweise aus einer Oberklase stammt. Schon viel früher hat man entdeckt, das Mixins (ich meine, die stammen aus Flavors, einem sehr frühen objektorientierten Lisp) alle guten Eigenschaften der Mehrfachvererbung haben ohne die Probleme. Formalisiert man Mixins und fügt ihnen abstrakte Methoden hinzu, hat man traits, ich kenne diesen Begriff wieder von Self. Inzwischen greifen immer mehr Sprachen (z.B. Scala und Fortress) dazu. Self hat zudem auch einen supersimplen Ansatz, der Serialisierungsproblem von Methoden zu lösen: Bei Mehrdeutigkeit gibt es Laufzeitfehler. Das missfällt aber Sprachtheoretikern, weil man so keine Vorhersagen über das Programm machen kann, ohne es auszuführen. Ach, es gibt auch jemanden, der hat Traits für JavaScript implementiert. Rubys Module sind konzeptionell übrigens auch Mixins bzw. Traits. In Python kann man die Mehrfachvererbung ebenfalls für Mixins nutzen, wenn man will. Komischerweise macht das kaum einer und irgendwie gibt es eine Art ungeschriebenes Gesetz, doch immer noch von einer Klasse zu erben. Ich glaube ja, das liegt daran, weil sich die Leute nicht davon trennen können, Vererbung gleichzeitig als Subtyp-Hierarchie anzusehen. Hatte ich schon mal Cecil erwähnt - das ist ein Zwitter aus Self und CommonLisp mit einem optionalen statischen Typsystem, welches Vererbung und Typen korrekt trennt. War eigentlich eine recht elegante Sprache, IMHO.

Stefan

[BlackJack]

@LanX: Wenn Du LISP programmieren willst, dann programmiere doch einfach in LISP. Wenn Du Dich gedanklich nicht auf eine andere Sprache einlassen willst, sondern in ihr genau so weiterprogrammieren willst, wie in einer Sprache die Du schon kennst, warum willst Du dann überhaupt eine andere Sprache verwenden. Mit dieser Argumentation kommt die Freiheit, dass jeder in seinen eigenen Mustern schreibt, und es für andere schwierig wird den Quelltext zu verstehen, warten, und zu erweitern. Eines *der* Probleme die ich mit LISP und Scheme habe, wenn sich jeder seine eigene DSL daraus zimmert.

Umgekehrt erwarte ich auch nicht, dass andere Sprachen wie Python funktionieren, zum Beispiel das es dort eine Python-artige Vererbung gibt. Im Grunde wirfst Du hier immer unterschwellig vor, die Leute wären zu unflexibel sich auf JavaScript einzulassen und hängen an den Spracheigenschaften von Java oder Python, und im Gegenzug jammerst Du rum, dass Du Muster von LISP nicht 1:1 auf Python übertragen kannst, und Dich die Sprache tatsächlich nötigt, sich mit ihrem OOP-Modell auseinanderzusetzen.

[Darii]

Sprich, da es dafür in Javascript keine Sprachmittel gibt, denkt sich jeder ein eigenes System aus, um gemeinsames Verhalten in die Prototypen zu kopieren.

Die wichtige Erkenntnis aus dem Self-Projekt (vor 20 Jahren) war, dass protoypische Vererbung mittels Delegation ein so mächtiges Sprachkonzept ist, dass man damit alle andere Systeme simulieren kann. Das man sich damit also verschiedene klassenbasierten Vererbungskonzepte selbst bauen kann, spricht IMHO für und nicht gegen die Sprache und die Wahl von Selfs System für JavaScript.

Aber im Gegensatz zu Self gibt es bei Javascript nur einen Prototypen. Bei Self kann man ja beliebig viele parent-Slots haben. JavaScript ist an der Stelle nicht flexibel genug um das mit Sprachmitteln zu auszugleichen. Ich hab nichts grundsätzliches gegen das Objektmodell von Javascript. Die Sprache selbst finde ich einfach nicht so toll (um nicht zu sagen grausam). Javascript ist einfach als reine Scriptsprache konzipiert und dementsprechend wurde sie auch entworfen. Siehe die ganzen grandiosem impliziten Typumwandlungen. Sowas ist bei dynamisch typisierten Sprachen tödlich. Dann knallt es nämlich nichtmal zur Laufzeit, sondern das Programm funktioniert einfach nicht wie gedacht.

In Python kann man die Mehrfachvererbung ebenfalls für Mixins nutzen, wenn man will. Komischerweise macht das kaum einer und irgendwie gibt es eine Art ungeschriebenes Gesetz, doch immer noch von einer Klasse zu erben.

Man könnte auch einfach import nutzen, leider ist aus irgendeinem mir unverständlichen Grund der sternchen-Import innerhalb von Klassen „deprecated“.

[LanX]

@LanX: Wenn Du LISP programmieren willst, dann programmiere doch einfach in LISP.

Na, hört sich an wie geh doch rüber, wenn's dir nicht passt.

Zurück zum Start, es ging darum dass nicht nur Javascript Defizite hat und ich z.B. bei Python "richtige Closures" und komplexe Lambdas vermisse.

Ich könnte auch ne lange Liste dessen abgeben, was ich in Perl vermisse. (Docstrings, Instanzvariablensigils wie in Ruby, Macros,...etc. pp.)

Das ist ein Diskussionsforum...wenn ich meine Kritik nicht äußere, kann ich nicht aus der Widerlegung lernen.

[BlackJack]

@Darii: Der ist nicht "deprecated". Schon in der ``import``-Doku von Python 1.4 steht der Satz `"The from form with * may only occur in a module scope."` Code der solche Importe nutzt(e) war also schon immer ausserhalb der Spezifikation, auch wenn der Compiler das früher mal durchgehen liess.

[Darii]

@Darii: Der ist nicht "deprecated". Schon in der ``import``-Doku von Python 1.4 steht der Satz `"The from form with * may only occur in a module scope."` Code der solche Importe nutzt(e) war also schon immer ausserhalb der Spezifikation, auch wenn der Compiler das früher mal durchgehen liess.

Deswegen die Anführungsstriche. Aber was heißt früher? In 2.6 gehts noch.

[LanX]

In Javascript muss/kann man ja wie in Python Variablen nicht explizit deklarieren (bis global, nonlokal, var). Die Deklaration erfolgt implizit durch Zuweisung. Wenn ich in Javascript eine Variable benutze ist sie automatisch global. Wenn ich in Java eine Variable deklariere ist sie lokal.

Code: Alles auswählen

function x() { foo = 23 }
x();
foo; // -> 23

"var" ist die Deklaration, und vergleichbar zu "int" usw in C und Java.

Die "undeklarierten" Variablen sind in JS auch nicht wirklich "global", sondern sind Attribute des umgebenden Objektes, sprich im Browser window.

Code: Alles auswählen

javascript: a="winki winki";alert(window.a)

wo JS nach nicht-lokalen Variablen sucht kannst du (halbwegs) mit with() steuern:

Code: Alles auswählen

O={a:"hier"};
with (O) {alert(a)};

[Darii]

"var" ist die Deklaration, und vergleichbar zu "int" usw in C und Java.

Habe ich doch geschrieben.

Die "undeklarierten" Variablen sind in JS auch nicht wirklich "global", sondern sind Attribute des umgebenden Objektes, sprich im Browser window.

Halt genauso global wie Python-global.

wo JS nach nicht-lokalen Variablen sucht kannst du (halbwegs) mit with() steuern:

Aber auch nur die Suche

Code: Alles auswählen

obj = {}
with(obj) { a = 23 }
obj.a // undefined

[LanX]

"var" ist die Deklaration, und vergleichbar zu "int" usw in C und Java.

Habe ich doch geschrieben.

Ja, aber in diesen, und den meisten anderen Sprachen brauchst du einen Deklarationsbefehl damit es lokal ist.

Bei Python (und wie wir jetzt wissen Ruby) ist es umgekehrt. Da brauchst/bräuchtest du ein nonlocal.¹

Dieser eine Punkt der dich an JS also nervt, begegnet dir fast überall wieder.

¿oder was hattest du gemeint mit:

Und die umständliche Scoping-Regel, der man zu verdanken hat, dass man vor praktisch jede Variable var schreiben muss.

?

1) wobei ich jetzt nicht glaube das "nonlocal" in Py selbst eine Deklaration ist, die Variable muss bereits in einem äußeren Scope deklariert worden sein, oder wird damit implizit eine globale Variable deklariert???