Die Zukunft von Python

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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 ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
BlackJack

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.
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

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:

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.
TUFKAB – the user formerly known as blackbird
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

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:

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'
>>>
TUFKAB – the user formerly known as blackbird
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

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.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
mitsuhiko
User
Beiträge: 1790
Registriert: Donnerstag 28. Oktober 2004, 16:33
Wohnort: Graz, Steiermark - Österreich
Kontaktdaten:

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.
TUFKAB – the user formerly known as blackbird
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

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

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

jens hat geschrieben:Wen es interessiert: lambda wird nun wohl doch nicht abgeschaft:
Hi Jens!

Danke für diese erfreuliche Nachricht. :-D

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 :-)
Zuletzt geändert von gerold am Montag 6. Februar 2006, 14:23, insgesamt 1-mal geändert.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
henning
User
Beiträge: 274
Registriert: Dienstag 26. Juli 2005, 18:37

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?
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

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
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Antworten