Die Zukunft von Python

[XT@ngel als Gast]

Hallo zusammen,
ich finde es nicht so wichtig ob nun <> oder != da die Änderung wirklich klein ist.
Auch write(), writeln() find ich super wenn man es genau so macht wie mit raw_input() => sys.stdin.readline()
Ist logisch und macht sinn.

Was mit nicht gefällt ist "Remove xrange() use range()".
Wieso eine zusätzliche option streichen?
Und auch Remove `x`. use repr(x) gefällt mir nicht.

Wenn das wirklich alles kommt was in PEP3000 so steht, multiple exceptions, optionales static typing wird das ne super Sache

MfG
Andreas

[jens]

optionales static typing

Ist das nicht eine Hürde weniger auf Weg zum Python compiler?

[Leonidas]

Ist logisch und macht sinn.

Eben, das ist ja ein großes Ziel, alte Designfehler auszumerzen.

Was mit nicht gefällt ist "Remove xrange() use range()".
Wieso eine zusätzliche option streichen?

Damit nun range immer Iteratoren ausgibt, und es kein xrange mehr braucht.

Und auch Remove `x`. use repr(x) gefällt mir nicht.

Ich habe repr selten gebraucht, aber ich würde `x` nie nutzen, dafür tippt es sich zu dumm und ist recht unlogisch.

Wenn das wirklich alles kommt was in PEP3000 so steht, multiple exceptions, optionales static typing wird das ne super Sache

Also das mit dem optionalen Static Typing finde ich nicht so toll.

[Gast]

Ist das nicht eine Hürde weniger auf Weg zum Python compiler?

Kann ich nicht sagen, dazu hab ich zu wenig Ahnung.
Ich schreib grad eine kleine Anwendung für QNX in C++, und da fällt mir wieder auf,wieso ich damals C++ hab fallen lassen. Dieses ewige compilieren .....

P.S Dein Post zum Codesnippets Index hab ich heute erst gesehen.
Urlaub sorry

Damit nun range immer Iteratoren ausgibt, und es kein xrange mehr braucht.

weil z.B range eine "echte" Liste erzeugt und xrange nur so tut als ob und das erstellen dann mir überlässt. Ausserdem scheint xrange langsamer zu sein.

Zu repr(), hab nochmal drüber nachgedacht und scheinst recht zu haben.
Wie ich mit Python angefangen habe fand ich

x = 5
print "Die Zahl ist : " + `5`

recht praktisch. Ist fast wie mit PHP

Bei static typing (optional) muss ich keinen type mehr prüfen und nur die Ausnahme abfangen. Ausserdem hoffe ich drauf, dass es mehr performance bringt und die Dokumentation erleichtert.

MfG
Andreas

[BlackJack]

Eigentlich sollte es möglichst nur einen offensichtlichen Weg geben um etwas auszudrücken, da sind also '<>' und '!=' um ungleich auszudrücken redundant. Der meiste, wenn nicht aller Quelltext in der Standardbibliothek, und das sind schon eine Menge Zeilen, benutzt '!='. Das, und das ungleich eben auch auf Objekten definiert werden kann, auf denen keine Ordnung definiert werden kann oder muss, macht '<>' eben zum Abschusskandidaten.

Zum angeblichen Wegfall von "print": Es soll kein Schlüsselwort mehr sein. Das war's auch schon. Es spricht nichts gegen eine Funktion die das gleiche tut. Aber natürlich nicht mit optionalen Klammern. Das wäre dann ein absoluter Sonderfall. Und Sonderfälle sind laut Zen nicht drin. Am Ende bekommt man ähnliche Phänomene wie bei Perl, wo "print (23 + 42) * 1000" als Ergebnis 65 ausgibt.

Zum Namen "writeln": der ist auch in einigen Sprachen gebräuchlich (z.B. Pascal, Io, Java), also keine grössere Hürde als "print". Ich fand "print" auch schon immer etwas komisch, weil ich eigentlich etwas auf den Bildschirm schreibe. Drucken ist eher etwas, was man mit dem Drucker macht. Das "print" stammt noch aus Zeiten wo an Computern kein Monitor, sondern eine elektrische Schreibmaschine als Ausgabegerät hängen konnte.

Das weglassen von ":" würde die jetzige, ziemlich einfache Regel "vor jedem eingerücktem Block kommt ein ':'" verletzen. Der Doppelpunkt ist sehr gut um Editoren ein automatisches Einrücken nach dem "Return" zu ermöglichen und trennt optisch die Parameterliste oder die Bedingung in Abfragen (if/while) vom Rest. Warum möchte man ihn abschaffen? Einen Tastendruck einsparen und dafür Lesbarkeit opfern?

Es heisst übrigens nicht ``MeinString.has_key("Bla")``, sonern ``"Blah" in MeinString``. Letzteres würde sogar funktionieren wenn `MeinString`, wie der Name vermuten lässt, eine Zeichenkette und kein dict() ist.

Ich finde die eingebauten Funktionen nicht schlecht, weil sie den Bedarf abdecken, den man sehr häufig benötigt. Wenn ich überall eine `len` Methode anbringen muss, dann müsste ich die auch überall aufs neue Dokumentieren. In Sprachen, wo so eine Funktion nicht vorgegeben ist, kommt auch oft ein Durcheinander zustande, weil einige Objekte die Funktion dann `len` nennen, andere `length` und wieder andere haben ein `size`. Java lässt grüssen.

Warum nicht ``liste.join('')``? Weil die `join`-Methode an Zeichenketten einmal definiert ist und mit allen iterierbaren Objekten als Argument funktioniert. Wenn man es andersherum machen würde, dann müsste die Methode an allen anderen (iteriertbaren) Objekten jedesmal neu definiert werden.

Das beseitigen von Backticks anstelle von `repr()` finde ich ziemlich gut. Die kann man nicht überall eingeben und bei manchen Zeichensätzen kann man sie nicht von normalen, einfachen Anführungsstrichen unterscheiden. Das ist Shell bzw. Perl Syntax. Eigentlich genau das, was man in Python nicht haben wollte. Solche Sonderzeichen sind auch ziemlich anfänger-unfreundlich. Wenn jemand nicht weiss, was `repr(x)` macht, dann weiss er wenigstens nach welchem (Befehls)wort er in der Doku suchen muss.

Optionale statische Typisierung finde ich auch nicht so toll. Das Python dynamisch ist, ist noch eine Hürde für den Einsatz in Firmen. Nicht statisch muss ja unsicher sein. Wenn dann optionale statische Typisierung dazukommt, dann wird man leider immer mehr statisch typisierten Quelltext sehen, weil der in den Firmen dann nicht mehr "optional" ist. Man gibt damit den dynamischen Vorteil von Python wegen fragwürdiger Sicherheit und angeblicher Geschwindigkeitsgewinne auf.

Ich verstehe auch nicht warum die Leute immer so versessen auf "Compiler" und/oder "EXE"n sind. Dann sollen sie doch bitte eine andere Sprache nehmen.

[Erwin]

Also wenn ich das so lese ... wird es mir ganz anders.

Was mich hatl stört, und immer stören wird, sind Veränderunge, dessen Sinn für den Anwender nur jener ist, daß er sich Umstellen muß.

Damit mein ich eben solche Dinge wie das ändern von 'Print' in 'write'(??) oder das mit dem input() ect..

Wenn sich Jemand länger mit der Sprache beschäftigt, oder neue Anfängt, so wie ich, muß er diese erst lernen.
Aber Sinn und Ziel des Ganzen ist es doch, die Sprache irgendwann recht gut zu beherschen, um endlich so richtig zum programmieren anfangen zu können.
Da sind Umstellunge in Form von Namensänderungen unnötiger Lernaufwand, finde ich.
Auch habe ich keine Lust ältere Scripte dann umzuändern (aus 'Print' was weis ich zu machen).
Nunja, ich könnte ja dann einfach bei 2.4.1 bleiben, aber wie sieht es auf dauer mit der Kompatibilität mit den anderen BS es dann aus?
Und wieso 2.4.1? Wieso nicht noch älter?

Ich würde es eher begrüßen und fände es auch wichtig, wenn man mehr auf die privaten Spieleentwickler eingehen würde und standardmäßig an Grafikoptionen was besseres mitreinpackt, als dieses Tkinter.
Dort solte, finde ich, was gemacht werden.
Den das fehlen von Transparenz, oder die fehlende Möglichkeit zum laden von BMP schreckt meiner Meinung nach mehr Leute ab, als die Tatsache, das mnache Befehle 'Print' heißen, und nicht anders.

Auch entwickelt es sich anderweitig mit den vielen Möglichkeiten das Ganze zu tode, finde ich.
Wenn man ein Problem lösen will, könnte man meinen, daß es die Lösung schon gibt. Wobei die Suche nach dem richten Befehl länger dauern kann, als es einfach mit paar anderen Befehlen selbst zu schreiben.
Vieles was da in Python drin ist, scheint mir eher belastend zu sein, als einfach. Und auch nicht auf jeden 100 % zutreffend, aber dafür um so verwirrender, wenn es darum geht, etwas vordefinertes anderweitig zu benutezn, weil vermutlich oft mehres dafür in Frage käme aber zugleich anderweitig als schwierig herrausstellt.

Der einzige Sinn wäre höchstens die Compatibilität, was den Namen und Befehlen zu anderen Sprachen betrifft.
Aber ich kann mir nicht vorstellen, daß man sich für eine Programmiersprach nur wegen identischen Namen entscheidet.
Macht zwar den Wechsel leichter ... aber dies allein wird kaum der Grund sein. Außerdem macht es auch dann den Wechsel weg von Python zur anderen Sprache ebenfalls leichter.
Ich hatte Heute eine andere Programmiersprache ausprobiert, die wiederum ganz andere Befehle hatte. Aber sie schien eben anderweitig interesant zu sein, was Deren Grafischen Möglichkeiten betrifft.
Leider hat ein Turitoral der anderen Programmiersprache meine Gerätedriver abgeschossen. Und sowas sollte nun wirklich nicht vorkommen.
Ansonsten ... wer weis, wärt Ihr mich vielleicht los geworden?
Eben wegen den Änderungen, die da scheibar kommen sollen. Das schreckt mich einfach ab.
Unwichtiges wird da, so sehe ich das, geändert, aber das wichtige scheint keinem zu interessieren.

Und noch was:
Wenn ich zurfrieden bin, hört man meist nichts.
Wenn mir aber was nicht paßt (zb. das Essen nicht schmeckt), dann fange ich an, mich bemerkbar zu machen.
Ich finde es riskant, auf die zu hören, denen Etwas nicht paßt, ohne dabei all Diejenigen, die nichts sagen, als Stille Zufriede zu betrachten. Nämlich jene Stille Zufriedene, die dann meist nach der Änderunge gehen, so zumindest mein Eindruck aus einem ONline-Spiel.

[mawe]

Hi!

Blackbird, Du verbindest "print" mit dem Drucken auf Papier, ich verbinde "write" mit dem Schreiben in eine Datei Der Name ist historisch bedingt (genauso wie, dass das erste Element eines Arrays den Index 0 hat. Das verwirrt Programmieranfänger sicher auch etwas). Aber jeder weiss was mit print gemeint ist.

Erwin, Dein Post klingt etwas depressiv .
Tk ist wahrscheinlich bei Python dabei, weils relativ klein ist. Ich finde auch, dass es am einfachsten zu bedienen ist. Es gab und gibt immer wieder die Diskussion wxPython statt Tk zu nehmen ...

BTW: Welche andere Programmiersprache hast Du Dir denn angesehen?

Gruß, mawe

[Erwin]

...
Ich verstehe auch nicht warum die Leute immer so versessen auf "Compiler" und/oder "EXE"n sind. Dann sollen sie doch bitte eine andere Sprache nehmen.

Ganz einfach:
Exe.Dateien lassen sich leichter verteilen.
Unkompiliertes wengier, weil dann auch der Interpreter mit muß. Weil es ist ja nicht sicher, ob Jeder den hat.
Wenn man also nur so vor sich hinprogrammieren will oder innerhalb einer Art geschlossenen Gemeinschaft, ist es nur noch wegen der Geschwindigkeit eine Exe-Datei von Interesse.
Aber wenn man seine Programme maximal unters Volk bringen will, dann geht dies eben nur mit Exe-Dateien.

...
Erwin, Dein Post klingt etwas depressiv .
Tk ist wahrscheinlich bei Python dabei, weils relativ klein ist. Ich finde auch, dass es am einfachsten zu bedienen ist. Es gab und gibt immer wieder die Diskussion wxPython statt Tk zu nehmen ...

BTW: Welche andere Programmiersprache hast Du Dir denn angesehen?
...

Bin auch etwas depresiv.
Ich will mehre Spielideen umsetzen, muß aber erst eine Sprache lernen.
So weit so gut. Geht eben nicht anders.
Aber dann gibt es so viele.
Und Python ... hat eben für meine Bedürfnisse leider paar Nachteile, was sich erst später rausstellte. Hm.. naja, aber nichts ist perfekt.
Hinzu kommt, in den Büchern wird zwar behandelt, wie man, naja, irgendwas macht, aber nicht wenn es um Grafiken geht. Anders ausgedrückt: Spieleentwicklerfeindlich.
Und nun muß ich hören, daß vieles geändert wird.
Und dafür habe ich mich jetzt 4-6 Wochen rumgeplagt?

Was ich mir angeschaut hatte, war PureBasic.
Das eine Turitoral war recht nett. Und es ging sofort daraum, ein Grafikspiel zu entwickeln, wenn auch ein ganz kleines Arcade-Spielchen.
Beim Zweiten ging es mehr wiederum um Übungen mit Grafik. Aber beim 3. Teil gab es eben Driverkonflikte. Durfte alles neu starten. Das wirkt alles andere als Vertrauenserweckend auf mich. Und ich dachte immer, sowas ähnmliches wäre C/C++ vorbehalten.

[mawe]

Hi Erwin!

Spieleentwicklung ist wohl nicht die Hauptanwendung von Python Wenn Du Dich aber umsiehst, es gibt dafür kaum etwas komfortableres als Pygame. Ich spreche leider nicht aus Erfahrung, ich hab mit Pygame noch nie etwas gemacht.

Und nun muß ich hören, daß vieles geändert wird.
Und dafür habe ich mich jetzt 4-6 Wochen rumgeplagt?

Alles was Du bis jetzt gelernt hast, wird für Dich in Zukunft nützlich sein. Die Änderungen die hier angesprochen werden betreffen ja eine Python-Version, die noch Jahre auf sich warten lassen kann. Du kannst also einfach Python so wie es jetzt ist weiterlernen und noch jahrelang damit programmieren

Gruß und gute Nacht, mawe

[XT@ngel]

Exe.Dateien lassen sich leichter verteilen.
Unkompiliertes wengier, weil dann auch der Interpreter mit muß. Weil es ist ja nicht sicher, ob Jeder den hat.
Wenn man also nur so vor sich hinprogrammieren will oder innerhalb einer Art geschlossenen Gemeinschaft, ist es nur noch wegen der Geschwindigkeit eine Exe-Datei von Interesse.
Aber wenn man seine Programme maximal unters Volk bringen will, dann geht dies eben nur mit Exe-Dateien.

Ist doch heute wirklich kein Problem mehr.
Siehe .Net/Mono, Java sowas kann ich mit nem installer mitliefern bzw. downloaden lassen.

Wenn Du Spiele unter Windows entwickeln willst (ernsthaft) kommst Du meiner Meinung nach an c/c++ und DirectX nicht vorbei.
Ich bekomm auch kein c++ programm hin wenn ich nicht meine beiden Bücher neben mir liegen habe.
Ich kanns einfach nicht so schnell runterschreiben wie PHP oder Python.

versessen auf "Compiler" und/oder "EXE"n sind. Dann sollen sie doch bitte eine andere Sprache nehmen

Kann ich nur zustimmen, für jedes Problem die richtige Sprache. Wenn man ein bisschen mehr Erfahrung hat einfach mal einen Blick über den Tellerrand werfen und schaun mit welche Sprache man sein Problem am besten lösen kann.

Gute Nacht
Andreas

[Leonidas]

Ich finde nicht, dass man Grafikfunktionen einbauen sollte, denn diese gibt es ja in Modulen, und um ehrlich zu sein, nutze ich auch Tkinter nicht, also könnte man Tkinter auch ausgleidern. Zusammen mit so tollen Sachen wie lib-old..

Was die grafischen Sachen angeht ist pygame gar nicht mal schlecht, wenn es nicht grad an den beschränkungen der libSDL leidet. Aber dann hat man halt Workarounds, z.B. dass man ein Bild nicht zweimal rotiert, sondern immer das Ursprungsbild. An sich ist pygame jedoch nach etwas einarbeitung ziemlich einfach zu nutzen, schwer ist es dann halt die ganzen Tricks für Spieleprogrammierung zu finden.

Solche pygame-Ausrutscher sind zB:
Rechtsverschiebung, Verschiebung nach unten, Verwischung (kann man auch konstruktiv nutzen) oder eben auch diese rotation. Ich kann euch sagen, die Bildstörungen die ich mit pygame generiert habe waren schon ziemlich witzig

Statische Typen bringen uns einem Compiler nicht näher, denn sie sind nur Optional. Dann muss der Compiler so oder so dynamitsche Typen unterstützen. Aber es gibt ja auch für Lisp Compiler, Lisp ist eine Sprache mit dynamischen Typen, ist ja auch kein unlösbares Problem. Das liegt zum großen Teil daran, dass es keine große Priorität hat, einen Python Compiler zu schreiben.

Davon mal abgesehen haben EXEn und ELFs auch Nachteile, so brauchen die einen msvcrt und die anderen libc. Und bei mir ist (war) es oft so, dass libc zu alt ist, deswegen freue ich mich immer über Pakete, die nicht kompiliert sind.

[Olliminatore]

Ich bin absolute dafür das ':' wegzulassen, nicht nur weil ich es häufig vergesse .
Das "Gegen" Argument für die Lesbarkeit in den Editoren , ist denke ich "nur" ein Problem der Editoren.

Und sonst finde ich auch die meissten Änderungen in PEP3000 sehr gut.
Es wird auch ein Schritt einsteigerfreundlicher, über die meissten hier angesprochenen Sachen bin ich als Anfänger in Python gestolpert.

Das ist erstmal alles was ich als "fast noch" Anfänger beisteuern kann.

[Leonidas]

Ich bin absolute dafür das ':' wegzulassen, nicht nur weil ich es häufig vergesse .
Das "Gegen" Argument für die Lesbarkeit in den Editoren , ist denke ich "nur" ein Problem der Editoren.

In Ruby ist das nicht und.. ich schreibe es dort dauernd hin, was mir einen SyntaxError einbringt.

[jens]

Ich hab noch einen...

Ich finde das .sort() ein bischen doof... Man kann es z.B. nicht so benutzen:

Code: Alles auswählen

keys = my_dict.keys().sort()

Es muß immer ein Zweizeiler sein:

Code: Alles auswählen

keys = my_dict.keys()
keys.sort()

Etwas verwirrend finde ich auch, das das zum None führt:

Code: Alles auswählen

keys = my_dict.keys()
keys = keys.sort()

[joe]

Ich finde das .sort() ein bischen doof...

Nimm sorted().
joe

[jens]

Das ist eine gute Idee... Nur sorted() gibt's erst in Python 2.4
Somit fällt es bei mir für CGI Programmierung erstmal unterm Tisch (Python v2.2.1)

[Leonidas]

Guck mal auf NeuereVersionen, dort findest du unter "Die Builtins" auch einen Link zu Backposts einiger neuerer Python Builtins.

[jens]

Ne, auf dem V-Server ist Python 2.4 drauf, aber bei Hosteurope leider nur die alte Version

[Leonidas]

Ach, jens, was hindert dich auf die Seite zu gehen, und den Link zu pflücken?

Na dann mach ichs, hier der Link. Dort siehst du, dass sum(), bool(), enumerate(), reversed(), sorted() und Sets implementiert werden. Und zwar so, dass du es auch aus python 2.2 verwenden kannst, du musst nur einen *-Import machen (wobei er mir hier eigentlich gerechtfertigt vorkommt).

[BlackJack]

Ich hab noch einen...

Ich finde das .sort() ein bischen doof... Man kann es z.B. nicht so benutzen:

Code: Alles auswählen

keys = my_dict.keys().sort()

Der Entscheidungsgrund dafür war, das alle Methoden, die ein Objekt verändern, statt ein neues zurückzugeben, keinen Rückgabewert haben bzw. das implizite `None` eben.