Das deutsche Python-Forum

jens hat geschrieben:[...]IMHO sind weder php, oder die c Variante wirklich schön gelöst.

Finde ich auch. Am schönsten sieht es immer noch so aus:

for i in xrange(10):
    print i

Ich habe cracki wohl falsch verstanden. Aber wenn die Semantik immer gleich bleiben soll, dann finde ich das eigentlich ziemlich uninteressant.

sape hat geschrieben:Hmm, bin nicht sicher ob ich das verstehe. Du meinst also so einen Superinterpreter der "alle" Sprachen (die als Skins vorliegen) interpretieren kann und auch ein Mischmasch aus allen Sprachen in einem sourcecode vorkommen kann?

Was meinst du? In einer Datei? Nein, natürlich nicht. Wäre zwar möglich, aber sehr unangenehm zu nutzen.
Aber sagen wir mal, ein Modul in Ruby zum implementieren und ein anderes In Python und dann von Python auf die Ruby-Klasse zugreifen, als wäre sie in Python geschrieben ist schon eher möglich. Macht IronPython in .NET mehr oder weniger auch so, auch wenn dort einige Einschränkungen sind zum Beispiel wenn es um Overloading geht. Jedenfalls wird der Python-Code von IronPython in IL kompiliert, und kann nun von jeder .NET-Sprache ganz normal verwendet werden.

sape:
Er meint quasi, dass aus verschiedenen Programmiersprachen der gleiche Bytecode erzeugt wird, so dass man die Programmiersprache selbst wählen kann, aber zum gleichen Ergebnis kommt.

Letztlich macht es IMHO aber mehr Sinn, direkt eine neue Sprache zu erschaffen, die eine saubere Syntax mit den Sprachfeatures der unterstützten Sprachen vereint, da letztere ja ohnehin implementiert werden müssen. Von den unterschiedlichen Denkweisen (ob forciert, ermöglicht oder zu bevorzugen) beim Programmieren noch abgesehen.

sape hat geschrieben:Am schönsten sieht es immer noch so aus:
Code: Alles auswählen
for i in xrange(10):
    print i

Nein, ich finde

Code: Alles auswählen

for i in 0..9:
    puts(i)
end

bis auf das 'end' klarer. Aber in Python gibt es keinen Syntactic Sugar für Range-Datentypen.

puts ist eine verdammte Altlast, die die Lesbarkeit vermindert. Und hast du nicht erst kürzlich gegen Altlasten gewettert?

Aber ja, die (aus Perl bekannten?) Ranges über a..z und dergleichen anstelle einer Funktion zu erzeugen ist schon angenehm, kompakt und intuitiv, hätte ich manchmal auch gerne.

Y0Gi hat geschrieben:puts ist eine verdammte Altlast, die die Lesbarkeit vermindert. Und hast du nicht erst kürzlich gegen Altlasten gewettert?

puts ist zumindest in Python keine Altlast, weil es das in Python gar nicht erst gibt. Aber gut, dann müssten wir die Funktion print mit puts überschreiben und fertig. Damit haben wir dann eine print-Funktion, die so in Python derzeit nicht einmal möglich ist.
An dieser Stelle hätte ich aber auch print(i) verwenden können, das stimmt, lediglich wären dann die Newlines verschwunden. In Ruby wird puts() für solche Dinge generell favorisiert, weil es sich so wie in Python aus print gewohnt verhält.

Aber mir gings in diesem Beispiel nicht um den Namen der Anzeigefunktion (und wenn wir dabei sind, ist weder puts och print ein Name, der die Funktionsweise exakt beschriebt), sondern um die Range-Syntax.

Leonidas hat geschrieben:
sape hat geschrieben:Am schönsten sieht es immer noch so aus:
Code: Alles auswählen
for i in xrange(10):
    print i
Nein, ich finde
Code: Alles auswählen
for i in 0..9:
    puts(i)
end
bis auf das 'end' klarer. Aber in Python gibt es keinen Syntactic Sugar für Range-Datentypen.

Sowas vermisse ich für Listen

Ich wünsche mir öfters sowas...

Code: Alles auswählen

li = [1..100]

anstat:

Code: Alles auswählen

li = [x for x in xrange(100)]

kommt das mal irgendwann für Python?

Kennt hier nicht jemand Guido persönlich und sagt ihn mal wir wollen alle [X..Y] haben?

...

Y0Gi, danke nun hab ichs verstanden.

lg

sape hat geschrieben:Sowas vermisse ich für Listen Ich wünsche mir öfters sowas...
Code: Alles auswählen
li = [1..100]
anstat:
Code: Alles auswählen
li = [x for x in xrange(100)]

Nimm doch li = range(1, 101)

Leonidas hat geschrieben: Nimm doch li = range(1, 101)

OK, aber was mache ich wenn ich a bis z haben will? li = [a..z] wäre da geil oder gleich li = [a..z..] + [A..Z] + [1..100]

alles andere ist nicht so elegant finde ich...

RTFM, mein Junge

Schau dir mal die Konstanten im Modul `string` an.

sape hat geschrieben:OK, aber was mache ich wenn ich a bis z haben will? li = [a..z] wäre da geil oder gleich li = [a..z..] + [A..Z] + [1..100]

Also so kompliziert ist das nun auch wieder nicht:

Code: Alles auswählen

import string
li = list(string.ascii_lowercase)
ls += list(string.ascii_uppercase) + range(1, 101)

Vor allem ignoriert es sowieso die deutschen Umlaute, also wäre a..z nur bedingt erweiterbar.

cracki hat geschrieben:mit skin meine ich wie der code aussieht. mit AST meine ich die semantik des codes. der gleiche code kann in php so aussehen, in js anders und in python wieder ganz anders. so verstaendlich?

Das funktioniert aber nicht wirklich, weil eine Sprache nicht nur aus Syntax, sondern eben auch aus Semantik besteht. Und die lässt sich bei unterschiedlichen Sprachen vielleicht noch in einen gemeinsamen Bytecode übersetzen, aber die Rücktransformierung in eine andere Sprache ist nicht immer möglich.

Wie übersetzt man zum Beispiel Bytecode oder AST mit dynamischem Scope (REXX oder Perl) in eine Sprache die nur lexikografischen Scope kennt, wie Python oder Java.

muss noch was loswerden. wenn man in einer sprache ausdruecken koennte, dass die argumente vor dem call nicht evaluiert werden sollen, sondern als callable oder AST, dann koennte man sowas machen:
Code: Alles auswählen
# macro() nimmt ne funktion, macht ein macro draus
while = macro( (condition, block) {
    loop = {
        if (condition()) {
            block()
            loop()
        }
    }
    loop()
})

a = 0
while(a < 10,
    print a**2
    a += 1
)
das bringt natuerlich wieder ganz andere probleme mit sich (bloecke muessten dann expressions sein, usw), ich weiss. waere aber ne ueberlegung wert, hm?

Solche Sprachen gibt's. Neben der Übergabe von Codeblöcken die erst in der aufgerufenen Funktion ausgewertet werden, kann man das auch per Metaprogrammierung lösen, also wirklich ein Makro das bei der Übersetzung ausgeführt und ersetzt wird. Mit Lisp oder Scheme kann man so etwas machen. Und bei D mit Templates oder dem ``lazy`` Schlüsselwort bei in der Argumentliste. Bei Nemerle ginge eine Makrolösung. Und in Io sieht die `while`-Schleife fast genau so aus. Io hat unheimlich wenige Schlüsselworte, alle Flusskontrollstukturen sind Methoden, die auf dem "Ur-Objekt" definiert sind. Hier ist die `while`-Schleife selbst implementiert:

Code: Alles auswählen

myWhile := method(
    loop(
        call evalArgAt(0) ifFalse(break)
        call evalArgAt(1)
    )
)

a := 0
myWhile(a < 10,
    a pow(2) linePrint
    a = a + 1
)

Jetzt möchte ich mal sehen wie das in einen AST übersetzt und dann in Python "rückübersetzt" aussehen soll!?

erstmal wird hier garnichts in bytecode uebersetzt. bytecode ist schon zu spaet.

so soll das dann sein: der AST ist die idealform des codes und ist so high level wie es geht. "code" wiederholt sich nicht mehr im AST.

die faehigkeiten von "skins" begreife ich selber nicht ganz, auch weil ich in die richtung erstmal nicht weiter denken will.
mein vorheriges beispiel php/c waere aber mit skins eher nicht machbar (so viel versteh ich mittlerweile). grund: die semantik der kernsprache (in dem fall die noch nicht erfundene idealsprache) scheint in jedem fall durch. wenn man also variablen vor dem gebrauch deklarieren muss oder *kann/darf*, dann ist das teil der semantik.
lediglich die parser regeln liessen sich veraendern, so dass man z.b. einem lisp einige der klammern abschneiden kann, einige infix-operatoren zur syntax hinzufuegen kann, gescheite syntax fuer lambda und blockstruktur dazumischt, etc...

was ich mit alledem eigentlich ausdruecken will:
es gibt keine sprache, die heute jeden menschen befriedigen kann. skins waeren eine moeglichkeit, eine sprache fuer alles zu erschaffen und diese dann fuer jeden anwendungsbereich zu verkleiden [1]

[1] es gibt genug high level sprachen, die sehr optimierten code ausspucken. maschinenperformance ist kein argument, schon garnicht bei den immer schnelleren prozessoren. viel mehr zaehlt, wie schnell, einfach und fehlerfrei der mensch ein programm schreiben kann. das erreicht man bekanntermassen weniger mit assembly als mit echten hochsprachen.

cracki hat geschrieben:was ich mit alledem eigentlich ausdruecken will:
es gibt keine sprache, die heute jeden menschen befriedigen kann. skins waeren eine moeglichkeit, eine sprache fuer alles zu erschaffen und diese dann fuer jeden anwendungsbereich zu verkleiden

So eine Sprache die alle toll finden wird es auch in Zukunft nicht geben. Bzw. ist das was Du beschreibst, die Sprache für alles, eigentlich Assembler und die Skins sind Compiler für die verschiedensten Programmiersprachen.

Hier nochmal Deine Idee von einer eigenen ``while``-Schleife in D:

Code: Alles auswählen

import std.stdio;

void myWhile(lazy bool test, void delegate () statement)
{
loop:
    if (! test()) return;
    statement();
    goto loop;
}

void main()
{
    ubyte a = 0;

    myWhile(a < 10, { writefln(a); ++a; });
}

BlackJack hat geschrieben:Hier nochmal Deine Idee von einer eigenen ``while``-Schleife in D:

Ist übrigens inzwischen in Version 1.0 erschienen, grad heute auf Golem gelesen, nachdem sie hier in den letzten Tagen ein Thema war.

Y0Gi hat geschrieben:RTFM, mein Junge

Schau dir mal die Konstanten im Modul `string` an.

1. Bin nicht dein Junge!

2. Habe ich schon
3. OMG, wäre hätte das gedachnt das `string` Konstanten definiert hat

-> Ja weiß ich, darum geht es aber nciht das war nur ein Beispiel wo noch sowas sinnvol wäre

4. [X..Y] wäre genauso "Sinnvoll" wie [1..100]

5. Nochmal ab den Post von Leonidas den Rest lesen!
6. SELF OWNED! (Wo wir gerade dabei sind schwachsinnige Akronyme wie RTFM zu nutzen)
7. Ich denke es ist angekommen oder?

Hey, sape, nur mit der Ruhe!

sape hat geschrieben:4. [X..Y] wäre genauso "Sinnvoll" wie [1..100]

Nicht ganz. Ich brauche wesentlich öfter Ranges mit Zahlen als mit Buchstaben. Vor allem geht es in a..z darum alle Kleinbuchstaben zu bekommen aber in 1..100 nicht darum alle Zahlen zu bekommen.

sape hat geschrieben:6. SELF OWNED! (Wo wir gerade dabei sind schwachsinnige Akronyme wie RTFM zu nutzen)
7. Ich denke es ist angekommen oder?

Hey, sind wir heute aggressiv? Ist irgendwie lächerlich, eine sachliche Diskussion auf ein Persönliches Flamen runterzuziehen.

Also, einmal mis zehn zählen, alternativ auch bis Zwanzigeins oder Zehnvierzig und durchatmen.

Das deutsche Python-Forum

Weiterentwicklung von JavaScript orientiert sich an Python