Die Zukunft von Python

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

[jens]

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

Naja, weil ich an debian-backports dachte und nicht daran, das ein "nur" ein python-source-backport ist

Das ist super cool - Danke!

[Leonidas]

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.

Das finde ich aber gar nicht so dumm, denn dann kann man sich immer sicher sein, dass es so ist.

Was ich noch geändert haben würde: die Modul importe so umbauen, dass beim Import des Modules das Modul auch wirklich wieder importiert wird, statt das Modul das noch vielleicht im Programm rumspukt wiederzuverwenden. reload(modulname) finde ich irgendwie nicht besonders..

[BlackJack]

Was ich noch geändert haben würde: die Modul importe so umbauen, dass beim Import des Modules das Modul auch wirklich wieder importiert wird, statt das Modul das noch vielleicht im Programm rumspukt wiederzuverwenden. reload(modulname) finde ich irgendwie nicht besonders..

Wie soll das denn funktionieren? Wenn ich ein Modul in zwei anderen Modulen importieren, dann möchte ich gerne das gleiche Modul in beiden haben und nicht in beiden eine neu geladene Kopie.

In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.

[Leonidas]

Wie soll das denn funktionieren? Wenn ich ein Modul in zwei anderen Modulen importieren, dann möchte ich gerne das gleiche Modul in beiden haben und nicht in beiden eine neu geladene Kopie.

Wieso? Wenn du in beiden Modulen Objekte erzeugst, sind es verschiedene Objekte, auch wenn alle Parameter beim erstellen gleich waren. Warum sollte das bei Modulen anders sein?

In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.

Ich finds einfach unlogisch, dass man ein Modul nicht neu laden kann, wenn man import modul macht. Das ist besonders ärgerlich im interaktiven Modus, wenn man ein Modul testet und gleichzeitig schreibt.

[tabellar]

In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.

Bei meinem "Astronauten Thema" habe ich so eine Fragestellung. Und zwar geht es darum, wenn man zB. einen Server laufen hat und man einzelne Module verändert, erweitert, hinzufügt, wie man eben diese zur Laufzeit nachladen kann, ohne Neustart des Servers.

Tabellar

[jens]

Wie in http://www.python-forum.de/viewtopic.php?p=20802#20802 festgestellt, möchte ich einen String-Formatter für Zahlen mit Tausender-Punkte

[BlackJack]

Wie soll das denn funktionieren? Wenn ich ein Modul in zwei anderen Modulen importieren, dann möchte ich gerne das gleiche Modul in beiden haben und nicht in beiden eine neu geladene Kopie.

Wieso? Wenn du in beiden Modulen Objekte erzeugst, sind es verschiedene Objekte, auch wenn alle Parameter beim erstellen gleich waren. Warum sollte das bei Modulen anders sein?

Weil Module etwas anderes sind als Klassen!? Das hätte ziemlich komische Konsequenzen. Man kann zum Beispiel keine Module mehr als gemeinsamen Namensraum nutzen. Und da Klassen auch Objekte sind, die dann bei jedem importieren neu erzeugt werden, wird es Probleme geben wenn man eine Instanz einer Klasse erzeugt und in einem anderen Modul zum Beispiel `isinstance()` benutzen möchte. Das wird immer `False` liefern, weil man durch den Import nicht mehr an ein Basisklassenobjekt kommt, sondern jedesmal ein neues erzeugt wird.

Und was ist mit Modulen, die beim Laden externen Code initialisieren, wie zum Beispiel GUI Bibliotheken? Viele erlauben das mehrfache Initialisieren auch gar nicht.

Und warum sollte man so grundlegende und von Natur aus eigentlich "einmalige" Sachen wie Funktionen und Klassen mehrfach übersetzten und im Speicher haben, obwohl die Daten zu 99% ziemlich statisch sind?

Dein Vorschlag würde sehr viel existierenden Code kaputtmachen.

In was für Situationen benötigt man in Programmen ein `reload()`? Ich persönlich habe es noch nie im Programm benutzt.

Ich finds einfach unlogisch, dass man ein Modul nicht neu laden kann, wenn man import modul macht. Das ist besonders ärgerlich im interaktiven Modus, wenn man ein Modul testet und gleichzeitig schreibt.

Dann kann man `reload()` benutzen oder `dreload()` in IPython. Aber selbst wenn hier ``import`` das Modul wirklich neu laden würde, löst das die Probleme nicht. Beim Testen hat man früher oder später Namen an irgendwelche Objekte aus einem Modul gebunden und vielleicht in Listen, Dictionaries oder als Callback etc. als Parameter in andere Objekte gesteckt. Wenn man nun das Modul neu lädt, dann bleiben existierende Bindungen an Objekte aus dem vorherigen laden trotzdem bestehen und man kämpft irgendwann mit einem Mix aus Objekten der verschiedenen "Generationen". Das Problem gibt's seit SmallTalk und lässt sich nur durch einen Neustart des Interpreters beheben. SmallTalk versucht ein wenig "intelligenter" zu sein und existierende Objekte durch die neuen auszuwechseln, aber manchmal bekommt man dadurch auch inkonsistente Objekte.

Interaktiv spiele ich nur ein wenig herum. Das Testen mache ich immer mit Testfunktionen oder Unittests die ich in einem frischen Interpreter starte. Sonst kann man sich nie sicher sein.

[mitsuhiko]

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.

Nein, weil es so auch mit tupeln läuft:

Code: Alles auswählen

>>> t = ("hallo", "du", "dumme", "welt", "war", "nur", "spass")
>>> ".".join(t)
'hallo.du.dumme.welt.war.nur.spass'

Und Tupel haben nun mal keine Öffentlichen Methoden.

[Leonidas]

Also ich kann mawes Meinung gut verstehen:

Code: Alles auswählen

irb(main):001:0> l = ["hallo", "du", "dumme", "welt", "war", "nur", "spass"]
=> ["hallo", "du", "dumme", "welt", "war", "nur", "spass"]
irb(main):002:0> l.join('.')
=> "hallo.du.dumme.welt.war.nur.spass"

Ruby hat zwar keine Tupeln, aber ich finde Rubys Verhalten in dem Fall klarer.

[mitsuhiko]

Also ich kann mawes Meinung gut verstehen:

Code: Alles auswählen

irb(main):001:0> l = ["hallo", "du", "dumme", "welt", "war", "nur", "spass"]
=> ["hallo", "du", "dumme", "welt", "war", "nur", "spass"]
irb(main):002:0> l.join('.')
=> "hallo.du.dumme.welt.war.nur.spass"

Ruby hat zwar keine Tupeln, aber ich finde Rubys Verhalten in dem Fall klarer.

Kann man ja kopieren:

Code: Alles auswählen

>>> class mylist (list):
...     def join(self, s):
...             return s.join(self)
...
>>> mylist(["hallo", "du", "dumme", "welt", "war", "nur", "spass"]).join(".")
'hallo.du.dumme.welt.war.nur.spass'
>>>

[Leonidas]

Klar, das geht. Aber nutzen tut es ja doch keiner, weil es nicht-Standart ist. In Ruby kann man zudem noch den list-Datentyp on-the-fly erweitern, ohne von ihm erben zu müssen:

Code: Alles auswählen

irb(main):040:0> class String
irb(main):041:1>     def join(l)
irb(main):042:2>         l.join(to_s())
irb(main):043:2>     end
irb(main):044:1> end
=> nil
irb(main):045:0> '.'.join(['abc', 'def'])
=> "abc.def"

So ein Feature wäre in Python vielleicht auch nicht schlecht Obwohl es auch ein paar Probleme mitbringt.

[mitsuhiko]

So ein Feature wäre in Python vielleicht auch nicht schlecht Obwohl es auch ein paar Probleme mitbringt.

Jup. Das wäre fein.
Das geht sogar bei Javascript mit dem prototype.

[jens]

Wen es interessiert: lambda wird nun wohl doch nicht abgeschaft:
http://mail.python.org/pipermail/python ... 60415.html

[gerold]

Wen es interessiert: lambda wird nun wohl doch nicht abgeschaft:

Hi Jens!

Danke für diese erfreuliche Nachricht.

Ich mag es gar nicht, wenn Python beschnitten wird. Es gibt lambda nun mal und wurde schon von vielen eingesetzt. Wenn es lambda nie gegeben hätte, dann wäre es wahrscheinlich nie jemandem richtig abgegangen, aber dieser Zug ist abgefahren. Wenn man jetzt lambda wegnimmt, dann würde es viele verärgerte Programmierer geben.

lg
Gerold


Edit: Aussage Entschärft

[henning]

Jo allerdings, ich finde es auch in jedem Fall besser sowas wie lambda zu behalten, als die Sprache da zu beschneiden.
(Und das obwohl ich es praktisch gar nicht nutze.)

Aber ich denke das Hauptargument gegen Lambda war gar nicht, dass es wenig genutzt wird, sondern viel mehr dass es zu leicht "falsch" genutzt wird (also um unübersichtlichen Code zu erzeugen), oder sehe ich das falsch?