Die Zukunft von Python

[Leonidas]

Ich habe es mir mal erlaubt, die Offtopic-Diskussion aus diesem Thread hirher zu verschieben, weil es sein könnte, das auch noch andere dazu was einwerfen möchten (das ich auch hoffe).

Kurze Vorgeschichte: Es ging um die Benutzung von <> in einem Quellcode.

Nur so zur Info: man sollte nicht <> sondern besser != verwenden weil: 1) die meisten (praktisch alle) Quelltexte != nutzen, 2) Es auf der to-deprecate Liste steht 3) weil != viel cooler ist *g*

Schöne Grüße,
Leonidas

[gerold]

2) Es auf der to-deprecate Liste steht 3)

Hi Leonidas!

Ich bin dafür, die Zeichenkombination <> nicht aussterben zu lassen. Schon seit dem Kindergarten gab es für mich nie eine logischere Zeichenkombination als <> für Ungleich.

>= größer oder gleich
<> kleiner oder größer

Finde ich fiel einfacher als != nicht gleich.

Nenne mich altmodisch -- so bin ich eben

lg
Gerold

[Leonidas]

Ich bin dafür, die Zeichenkombination <> nicht aussterben zu lassen. Schon seit dem Kindergarten gab es für mich nie eine logischere Zeichenkombination als <> für Ungleich.

Ich sag nur, wie es in PEP 3000 steht.. und um ehrlich zu sein, je länger ich über die Vorschläge darin überlege, desto besser gefallen sie mir (die meisten, nicht alle).

>= größer oder gleich
<> kleiner oder größer

Finde ich fiel einfacher als != nicht gleich.

Nenne mich altmodisch -- so bin ich eben

Ich persönlich finde != logischer, denn:

Code: Alles auswählen

>>> 1 != 2
True
>>> 1 <> 2
True
>>> 1 != '2'
True
>>> 1 <> '2' # wie, ist ein String nun größer oder kleiner als eine Zahl?
True

Und das ist mit allen Objektvergleichen, die meisten Objekte sind gleich, oder ungleich, nicht kleiner oder größer.

Aber gut, das ist nur meine Meinung, bei mir spielt noch rein, dass ich noch eine Abneigung dagegen habe weil VB auch <> benutzt

[gerold]

Ich bin dafür, die Zeichenkombination <> nicht aussterben zu lassen.

Ich persönlich finde != logischer, denn:

Code: Alles auswählen

>>> 1 != 2
True
>>> 1 <> 2
True
>>> 1 != '2'
True
>>> 1 <> '2' # wie, ist ein String nun größer oder kleiner als eine Zahl?
True

Und das ist mit allen Objektvergleichen, die meisten Objekte sind gleich, oder ungleich, nicht kleiner oder größer.

Hi Leonidas!

Du hast recht, bei Objektvergleichen hinkt mein Vergleich ein wenig

Trotzdem finde ich es nicht richtig, dass so etwas aus der Sprache gestrichen werden soll. Warum denn auch? Es wird weiterhin Leute wie mich geben, die sich solche Änderungen nicht gerne vorschreiben lassen wollen. Ich finde es einfach "realistischer", wenn ich Zahlenwerte mit <> vergleichen kann. Und weil ich niemandem für solche Sanktionen eine aufs Maul geben kann, schreibe ich einfach hier, dass es mir nicht passt.

Nichts für ungut -- bin eigentlich ein friedlicher Mensch Es macht mich nur wild, wenn mir jemand etwas ohne Grund wegnehmen will -- auch wenn es nur die Freiheit ist, <> statt != benutzen zu können.

lg
Gerold

[gerold]

Dieses PEP http://www.python.org/peps/pep-3000.html kommt mir teilweise wie eine Rezepturänderung bei Coca Cola vor. Es wird einfach an der Rezeptur gedreht, weil man mal wieder etwas neues ausprobieren möchte.

Wenn ich nur besser Englisch beherrschen würde, dann könnte man den Authoren die Meinung sagen...

Ich gehe jetzt einen Saufen. Dieser Tag ist nicht mehr zu retten.

[Leonidas]

Wenn ich nur besser Englisch beherrschen würde, dann könnte man den Authoren die Meinung sagen...

Du kannst auch Niederländisch schreiben, weil PEP3000 ist von GvR.

Eine andere Sache ist noch, ob und wie alles darin in Python 3k/3.0 realisiert wird.

Jedoch finde ich, es könnten noch mehr so tolle Goodies eingebaut werden wie LCs und co, da geht der Entwurf von Ruby2 wesentlich weiter als der von Python 3k.

[gerold]

Hi Leonidas!

Du kannst auch Niederländisch schreiben, weil PEP3000 ist von GvR.

...nicht mal Niederländisch schreiben können. Wie nachlässig von mir...

Eine andere Sache ist noch, ob und wie alles darin in Python 3k/3.0 realisiert wird.

Hoffentlich nicht. Wenn ich mir nur vorstelle, print durch writeln zu ersetzen... Dadurch werden so manche erste Erfolgserlebnisse mit Python versaut. Jeder hat einen anderen Einstieg in eine Programmiersprache. print hat jeder schon irgendeinmal gehört und jeder versucht sich zuerst mit print "Hallo". Warum soll man solche Erfolgserlebnisse erschweren? Es gibt Befehle, die so einfach wie möglich gehalten werden müssen. Ich finde sogar, print soll es egal sein, ob es mit oder ohne Klammern aufgerufen wird.

Weiter gehts mit eval(sys.stdin.readline()).
Das hat sich doch sicher irgendein Java-Fetischist ausgedacht. --> Dinge die ich häufig brauche, sollen einfach sein -- der Rest möglich.
Ich habe nichts gegen eval(sys.stdin.readline()) -- es darf aber nicht einen einfacheren Befehl wie input() ersetzen.

Jedoch finde ich, es könnten noch mehr so tolle Goodies eingebaut werden wie LCs und co,

Da stimme ich dir voll und ganz zu.

Man soll nur vorsichtig beim Ausmisten sein.

Nur weil es einige nicht benutzen oder für unnötig halten, müssen Sie es nicht den anderen, die es gerne benutzen und lieb gewonnen haben, nehmen.

lg
Gerold


PS: Ich glaube, dass ich diese Diskussion im falschen Thread angefangen habe.

[Leonidas]

Eine andere Sache ist noch, ob und wie alles darin in Python 3k/3.0 realisiert wird.

Hoffentlich nicht. Wenn ich mir nur vorstelle, print durch writeln zu ersetzen... Dadurch werden so manche erste Erfolgserlebnisse mit Python versaut. Jeder hat einen anderen Einstieg in eine Programmiersprache. print hat jeder schon irgendeinmal gehört und jeder versucht sich zuerst mit print "Hallo". Warum soll man solche Erfolgserlebnisse erschweren? Es gibt Befehle, die so einfach wie möglich gehalten werden müssen. Ich finde sogar, print soll es egal sein, ob es mit oder ohne Klammern aufgerufen wird.

Ich nutze zwar auch oft print, jedoch habe ich (wenngleich etwas Ideologische, oder wie man das nennt) Probleme Damit. Print ist ein Schlüsselwort, was ich eigentlich uüberflüssig finde, denn es lässt sich einfach auch als Funktion realisieren, wo wie es in Ruby ist: puts() (Wobei man dort die Klammern weglassen darf, das ist so eine Eigenheit).

Weiter gehts mit eval(sys.stdin.readline()).
Das hat sich doch sicher irgendein Java-Fetischist ausgedacht. --> Dinge die ich häufig brauche, sollen einfach ein -- der Rest möglich.
Ich habe nichts gegen eval(sys.stdin.readline()) -- es darf aber nicht einen einfacheren Befehl wie input() ersetzen.

Naja, gut das scheint tatsächlich etwas übertrieben zu sein, jedoch kann man auch

Code: Alles auswählen

def input():
    return eval(sys.stdin.readline())

machen und damit gibt es input wieder. Das soll wohl dem "Zen of Python" entsprechen

There should be one-- and preferably only one --obvious way to do it.

Man soll nur vorsichtig beim Ausmisten sein.

Nur weil es einige nicht benutzen oder für unnötig halten, müssen Sie es nicht den anderen, die es gerne benutzen und lieb gewonnen haben, nehmen.

Deswegen ist es erst frühestens für Python 3k gedacht. Es gibt jedoch eine grenze, wie weit man Rückwährtskompatibel ist, so kannst du fast immer direkt Python 1.5.x Programme mit Python 2.4 ausführen, ohne jegliche Änderung, stellst aber bei Betrachtung des Quellcodes fest, wieviel das aktuelle Python angenehmer ist. Und irgendwann kommt man halt zu Änderungen die nicht mehr rückwärtskompatibel sind.

PS: Ich glaube, dass ich diese Diskussion im falschen Thread angefangen habe.

Hab ihn gesplittet, vielleicht werden noch andere User ihre Meinung zu dem ganzen äußern.

[jens]

print wegzurationalisieren halte ich auch für nicht sinnvoll! Gerade für kleine Tests ist es sehr wertvoll und vor allem schnell
Jedoch in einem "richtigen" Programm könnte ich mir durchaus auch vorstellen immer mit .write() eines File-like-Objekt zu arbeiten und das kann ja dann sys.stdout sein

Jedoch hätte ich da noch eine Idee:
Warum muß man eine Funktionsdefinition mit einem ":" abschließen? Ich fänds super wenn man es weglassen könnte!

Warum heißt es MeinString.has_key("BlaBla") aber len( MeinString ) und nicht MeinString.len() oder auch nur MeinString.len ?
Python ist zwar schon super konsistent, aber es gibt da noch ein paar Kleinigkeiten

Ach, und da wir schon mal beim Nörgeln sind: Die Doku sollte definitiv besser werden! Mit viel mehr Beispielen! Wäre auch nicht schlecht wenn jede Seite mit einem Link zu einer Wiki-Seite versehen wird, die jeder erweitern kann oder besser noch, die ganze Referenz als Wiki "freigeben"!!!

[Leonidas]

print wegzurationalisieren halte ich auch für nicht sinnvoll! Gerade für kleine Tests ist es sehr wertvoll und vor allem schnell
Jedoch in einem "richtigen" Programm könnte ich mir durchaus auch vorstellen immer mit .write() eines File-like-Objekt zu arbeiten und das kann ja dann sys.stdout sein

Ich hätte es halt recht gerne als "richtige" Funktion, nicht als Keyword. Genauso mag ich das del-Keyword nicht. Keywords lassen sich so schlecht überschreiben

Jedoch hätte ich da noch eine Idee:
Warum muß man eine Funktionsdefinition mit einem ":" abschließen? Ich fänds super wenn man es weglassen könnte!

Weil man sonst die Funktionen nicht mehr so einfach in eine Zeile schreiben könnte (vielleicht).

Warum heißt es MeinString.has_key("BlaBla") aber len( MeinString ) und nicht MeinString.len() oder auch nur MeinString.len ?
Python ist zwar schon super konsistent, aber es gibt da noch ein paar Kleinigkeiten

Das ist einfach Broken by design aus älteren Pythonversionen, denn es gab schon praktisch immer len(). Und das beste kommt noch, denn len() ruft in Wirklichkeit "Leonidas".__len__() auf! Schade, dass man die Klassen nicht überschreiben oder erweitern kann sonst hätte ich es schon längst so umgebaut, dass es .len() gäbe.

Ach, und da wir schon mal beim Nörgeln sind: Die Doku sollte definitiv besser werden! Mit viel mehr Beispielen! Wäre auch nicht schlecht wenn jede Seite mit einem Link zu einer Wiki-Seite versehen wird, die jeder erweitern kann oder besser noch, die ganze Referenz als Wiki "freigeben"!!!

Also um ehlich zu sein, finde ich die Doku meist sehr gut, denn oft darf ich mich freuen, wenn es zu etwas überhaput Doku gibt. Und für Beispiele ist das Python Cookbook genial. Die Doku lässt sich nicht als Wiki freigeben, denn sie wird für jede Version aufs neue aus den LaTeX Sourcen erstellt, und ich denke nicht, dass allzuviele Wiki-User LaTeX schreiben können oder auch nur wollen

[jens]

Jedoch hätte ich da noch eine Idee:
Warum muß man eine Funktionsdefinition mit einem ":" abschließen? Ich fänds super wenn man es weglassen könnte!

Weil man sonst die Funktionen nicht mehr so einfach in eine Zeile schreiben könnte (vielleicht).

Das wäre nicht wirklich nötig, da ")" die Sache abschließt:

Code: Alles auswählen

def meinPrint(daten) print daten

Code: Alles auswählen

def print_zeile() print "-"*80

[mawe]

Hi!

Warum muß man eine Funktionsdefinition mit einem ":" abschließen? Ich fänds super wenn man es weglassen könnte!

Warum heißt es MeinString.has_key("BlaBla") aber len( MeinString ) und nicht MeinString.len() oder auch nur MeinString.len ?

Vielleicht solltest Du Dir mal Ruby ansehen. Dort sind die beiden Dinge so wie Du sie haben willst
Über len() hab ich mich in einem anderen Thread auch schon mal beschwert, irgendwas.len wäre logischer. Aber, mal im Ernst, so viele Schlüsselwörter gibts auch wieder nicht, als dass man sich die nicht merken könnte

Was mich besonders nervt (hab ich damals auch schon gesagt), ist join.

Code: Alles auswählen

''.join(liste)   # warum so
liste.join('')   # und nicht so?

Ich find das völlig unlogisch.

Die Doku find ich eigentlich ok (vor allem im Vergleich zu Ruby). Die Idee von jens mit dem Wiki find ich genial.

Ach ja, anstatt die Spache (Syntax, Schlüsselwörter, ...) zu verändern, sollten sich die Herrn Entwickler mal die Module ansehen, umgestalten und ausmisten. Wir hatten ja kürzlich das Modul shutil. Das kennt kein Mensch (vielleicht wegen dem Namen?), und die meisten Funktionen die ich darin vermuten würde, befinden sich in os.

Gruß, mawe

[jens]

Vielleicht sollten wir hier mal eine Petition erstellen und einreichen
Könnten wir ja im "Forum Wiki" machen...

[mawe]

Weil man sonst die Funktionen nicht mehr so einfach in eine Zeile schreiben könnte (vielleicht).

Könnte man ja auch optional machen. Kein : wenn Block in nächster Zeile beginnt, : wenn er in der selben Zeile ist (so wie bei ;).

[Leonidas]

Okay, wenn ihr Lust habt, könnt ihr ab sofort eure Vorschläge auch in der PythonWunschliste verewigen. ich werde mein Zeug auch da reinschreiben, wenn ich mal wieder Zeit habe. Aber Diskussion dieser Änderungen ist besser hier zu führen

[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.