Das deutsche Python-Forum

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

Leonidas hat geschrieben:

BlackJack hat geschrieben: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.

BlackJack hat geschrieben: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.

mawe hat geschrieben: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:
Und Tupel haben nun mal keine Öffentlichen Methoden.

Also ich kann mawes Meinung gut verstehen: Ruby hat zwar keine Tupeln, aber ich finde Rubys Verhalten in dem Fall klarer.

Leonidas hat geschrieben: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:

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:
So ein Feature wäre in Python vielleicht auch nicht schlecht Obwohl es auch ein paar Probleme mitbringt.

Leonidas hat geschrieben: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.

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

jens hat geschrieben: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

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?

henning hat geschrieben: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?

Hi Henning!

Was der wirkliche Grund für die Diskussion "Lambda abzuschaffen" war, kann ich nicht sagen. Ich habe die Diskussionen über Lambda nicht mitverfolgt und kann dazu keine fundierte Aussage treffen. Deshalb habe ich meinen vorherigen Beitrag noch einmal geändert.

Reine Gefühlssache: Für mich ist in diesem Fall nur wichtig, dass Dinge nicht abgeschafft werden, die ich persönlich ab und zu mal einsetzte und mir dabei denke, dass es doch schön ist, wenn es so etwas gibt.

Es gibt Funktionen, die als Argument eine andere Funktion erwarten. Als ich noch TkInter verwendet habe, bin ich öfter in eine Situation geraten, die ohne lambda umständlicher zu lösen gewesen wäre. Speziell die Zuweisung von Events wurde dadurch erleichtert. Dadurch kann man z.B. bereits beim Zuweisen der Event-Funktion einen Parameter übergeben.

Mein Fazit: Das Abschaffen von lambda hätte manche meiner Programme länger und komplizierter gemacht.

lg
Gerold