Das deutsche Python-Forum

a) Metaklassen gab es schon mit 1.5
b) Dekoratoren wurden eingebaut weil mehr und mehr Leute Dekorator Funktionen geschrieben haben (siehe auch classmethod/staticmethod/property etc.)
c) kann man das nicht mit VB vergleichen
d) wird mit python3 die Sprache eher einfacher als komplizierter (nur noch eine Klassenart, print kein Statement mit eigentümlicher Verwendung [softspace anyone?], integer != float division etc.)

@birkenfeld: Ich finde den Namen etwas "unpythonisch", nicht nur wegen dem grossen 'M', sondern auch weil's so abgekürzt ist. Wie wär's mit `map_monad_and_ignore_results()`.

mitsuhiko hat geschrieben:print kein Statement mit eigentümlicher Verwendung [softspace anyone?]

Jo, jetzt faellt mir wieder ein, warum ich print, so wie es ist, nicht mag. Die Sache mit "Komma am Ende unterbindet Newline" ist doch auch total komisch.

Mmh. Ich glaube, ich muss mir das Python 3.0-Alpha demnaechst mal installieren und ausprobieren, der Thread hat mich ja schon neugierig gemacht.

Hi!

Ich glaube, bei der "print"-Sache habe ich keinen guten Stand.

lg
Gerold

@Rebecca: Das mit dem Komma am Ende ist überhaupt nicht komisch. Das hat meine erste Programmiersprache, Commodore BASIC auf'm C64 auch so ähnlich, nur ist's da das Semikolon. Das Komma ist ein "Tab". Hab's danach bei allen anderen Sprachen vermisst, bis Python daher kam.

Also wirst du uns nach dem Release von Python 3.0 final verlassen? Na ich hoffe mal nicht

Ich bin noch schwer am überlegen. ``goto`` mit Zeilennummer als Ziel haben sie in die 3.0 auch noch nicht eingebaut. Diese strukturierte Programmierung und die Ausnahmen sind ja irgendwie nur eine Notlösung.

Wenn man schon mal dabei ist, könnte man doch auch gleich die Statements und built-ins auf drei Zeichen normieren:

whl, lst, dct, ift (if then), elf, wth, ..., und natürlich for

diese zeilenbezogene gotos....
was ist wenn ich dan zum beispiel ganz oben im file noch ein kommentar hinzufuege!?


offtopic im offtopic: (lehst euch mal die "vorteile" durch)
https://layer-ads.de/qualitaet.htm

Deswegen nummeriert man in groesseren Schritten:
Dann kannst man zwischen Zeile 10 und 20 noch beruhigt eine Zeile 15 einfuegen...

Jede ernst zu nehmende Erweiterung des eingebauten BASICs hat auch einen RENUMBER-Befehl mit dem man Zeilen neu durchnummerieren kann, wobei selbstverständlich die Sprungbefehle angepasst werden. So etwas selber zu schreiben ist auch eine gute Übung, ob man das interne Speicherformat von BASIC auf dem C64 verstanden hat.

o mein gott!

mein informatik lehrer tut mir immer mehr leid

aber gut, wenn ich bedenke was in 10 jahren alles moeglich sein wird...

Dabei sind wir noch gar nicht bei den Lochkarten angekommen.

Und noch eine Anmerkung zu Metaklassen, die du auch kritisiert hast. Das Typ/Objekt/Instanz System in Python weicht etwas vom klassischen Ansatz der meisten anderen Programmiersprachen ab und ist deshalb auch nicht so einfach zu verstehen.

Zum einen braucht man Metaklassen aber sowieso eher selten und wenn dann lassen sie sich auch gut verstecken und tragen wesentlich zur besseren Lesbarkeit und Einfachheit des Programms bei. Das beste Beispiel hier sind wohl die Django Model Klassen, welche beim Erzeugen auch gleich alle SQL-Statements anlegen und auführen, aber es gibt auch noch eine Vielzahl von anderen Klassen wo man es vermutlich gar nicht merkt.

Also mir gefällt die Entwicklung bei Python bis jetzt noch sehr gut und hoffe das die Performance von Py3k (genauer gesagt von der CPython Version) auch noch etwas zunimmt bis zum Release.

Gruß
Christoph

Rebecca hat geschrieben:Dabei sind wir noch gar nicht bei den Lochkarten angekommen.

bitte einen Grundkurs!

War heute im Buchladen und habe mir die dritte Ausgabe von "Programming Python" angesehen, die für Python 2.5 aktualisiert wurde. Das Buch hat stolze 1600 Seiten und ist noch um einige Seiten dicker als Programming Ruby (Pickaxe)
Ich glaube ich habe in all den Jahren zusammen nie 1600 Seiten Python-Dokumentation gelesen

hab das alte hier bei mir rummliegen: 1552 seiten
insofern...


der autor drueckt alles einfach viel zu kompliziert aus
(und schreibt alles in camelCase )

Leonidas hat geschrieben:War heute im Buchladen und habe mir die dritte Ausgabe von "Programming Python" angesehen, die für Python 2.5 aktualisiert wurde. Das Buch hat stolze 1600 Seiten und ist noch um einige Seiten dicker als Programming Ruby (Pickaxe)
Ich glaube ich habe in all den Jahren zusammen nie 1600 Seiten Python-Dokumentation gelesen

das steht hier neben mir auf dem Tisch ... und das ist sooo schwer........ und es past auch nicht in die Handtasche und schon gar nicht mit Notebook zusammen ..... aber gelesen hab ich es noch lange nicht fertig ....

Leonidas hat geschrieben:und ist noch um einige Seiten dicker als Programming Ruby (Pickaxe)

Also ist Python jetzt schon komplizierter als Ruby?

Nee, aber man kann mehr mit machen, und das muß halt beschrieben werden