@classmethod ganz neu entdeckt (und Namespaces)

[poker]

Gerold, ehrlich das doch IMO voll O.K. Wenn man global's braucht dann braucht man sie halt Viele integrierten Debug-Kits oder Logger machen es auch einfach so (Obwohl ich mir diesbezüglich eine real AOP in Python wünschen würde.).

BTW: Den get und set würde ich aber dennoch ein property spendieren; fühlt sich angenehmer an.

mfg

[gerold]

Nun suchst du nach einer Möglichkeit zusammengehöriges Optisch zu strukturieren und darüber zuzugreifen. Ich hab zwar dein Problem (hoffentlich) nun erfasst aber es will sich mir nicht so ganz erschließen weshalb es ein Problem darstellt? Warum packst du es nicht einfach in der Klasse und erzeugst eine Instanz.

Hallo poker!

Das ist es ja. -- Das war nie ein Problem für mich und es war und ist DIE Lösung, die ich seit ich Python kenne so einsetze.

...bis jemand schrieb, dass man seiner Meinung nach Klassen nicht für so etwas einsetzen soll. Methoden, die nicht auf ein Attribut der Klasseninstanz zugreifen müssen, gehören nicht in eine Klasse. --- Jetzt bin ich in der Phase, diese Aussage zu überprüfen und meine Methode gegenüber anderen Alternativen abzuwiegen. Ich habe jetzt schon einiges durchprobiert: auslagern in Module, statische Methoden, Klassenmethoden,... Und das Binden von Funktionen an ein intern erstelltes Modul-Objekt wird mich die nächsten Tage auch noch beschäftigen. Es genügt nicht, einfach nur ein kurzes Beispiel auszuprobieren. Solche Dinge müssen sich in der Praxis bewähren und zum Stil eines Programmierers passen.

Wir sind jetzt zwar komplett von der ursprünglichen Fragestellung weg gekommen, aber das macht ja nichts.

mfg
Gerold

[poker]

Hab den Code vorhin nur kurz überfolgen und dabei ist mir garnicht aufgefallen, dass deine Klasse keinerlei Zustände kennt Ok, so mancher Logger kennt auch keine

Methoden, die nicht auf ein Attribut der Klasseninstanz zugreifen müssen, gehören nicht in eine Klasse.

Ja Das ist eben die "reine" Lehre. An für sich ist das ja auch richtig. Ich hole mal ein wenig aus, da wir ja schon ein wenig OT sind:

Eine Klasse mit einer Ansammlung von Methoden (=Verhalten) ohne Attribute (=Zustände) auf die sie Zugreifen, bedeutet nach der OOP Lehre => Ein Objekt mit verhalten ohne Zustand. Wie kann aber ein Entität Verhalten ohne Zustände haben?! Das ist paradox. Selbst das primitivste Lebewesen hat Zustände, die erst ein gewisses Verhalten begünstigen. Entfernen wir uns davon und gehen über zu Objekten wie z.B. ein Auto, trifft das auch darauf zu: Ohne Benzin (=Zustand) keine Fortbewegung (=Verhalten).

Deshalb wird OOP ad absurdum geführt, wenn man das dahinterliegende Konzept (Modellierung von Objekten die eine Einheit aus Zuständen und Verhalten bilden) dafür benutzt um einfach Funktionen darin zu kapseln ohne das die Klasse irgend einen Zustand kennt, der Verändert werden kann oder in Abhängigkeit dessen das Verhalten gesteuert werden kann.

Bestes Beispiel dafür ist Java, das als rein OOP Sprache entwickelt wurde. Irgendwann hat man doch gemerkt, das man ganz ohne Funktionen nicht auskommt. Was haben die daraufhin gemacht? Klar, statics und classmethods eingeführt. Damit wurden sie ein stückweiter weniger dem angestrebten "Ideal" gerecht => Ganz ohne geht es dann doch nicht Und durch die "Integrierung" von AOP haben die sich dann gänzlich von dem "Ideal" OOP entfernt.

Worauf ich nun letztendlich raus will ist, das ein oder einige wenige erkorenen Lösungen für ein Problem nur soviel Wert sind, bis man an die grenzen dessen stößt. Ab da an muss man andere Wege beschreiten und Konvention den Rücken kehren um neue Lösungen zu finden.

Bei dir stoßen die Lösungen, nun reine zusammengehörige Funktionen zu benutzen die im module space kleben, in so fern an ihre Grenzen, als das du dadurch für dein empfinden ein zu sehr fragmentierten Code erhälst. Du suchst für dich einen Weg zusammengehöriges optisch durch Einrückungen zu strukturieren. Wenn du dabei ein besseres Gefühl hast, dann wird dich da keiner hindern. -- Vielleicht wäre es in der Tat nicht schlecht ein namesapce-statement in Python einzuführen, damit man die Möglichkeit hat zusammengehörige Funktionen optisch zu gruppieren.

Einer meiner würde es so machen wenn es wirklich nur Funktionen sind ohne dazugehörige Zustände:

Code: Alles auswählen

## Funktions for getting and setting day at id's
def get_last_day_at_id():
    pass

def set_last_day_at_id(new_id):
    pass

## other stuff

Die ## gefolgt von einer kurzen Info sind für mich genug optisch Abgrenzung und Strukturierung.

mfg

edit: typos & struct

[Leonidas]

Vielleicht wäre es in der Tat nicht schlecht ein namesapce-statement in Python einzuführen, damit man die Möglichkeit hat zusammengehörige Funktionen optisch zu gruppieren.

Machbar ist es schon jetzt. Man könnte entweder über die Codecs gehen und dort den Quellcode vorher abfangen und in anderen Konstrukte übersetzen oder versuchen den Interpreter so zu hacken, dass er das unterstützt (wobei ich da nicht sicher bin, was geht und was nicht).

Andererseits verstehe ich immer noch nicht, warum man nicht einfach ein zusätzliches Modul nimmt. Die Diskussion habe ich heute schon mal geführt, bei der es darum ging zusätzliche Dateien zu erstellen, statt bereits vorhandene zu verkomplizieren.

[poker]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

@Zusätzliches Modul: Ich denke gerold geht es darum nur ein Script weiter zu geben anstelle von einem ganzes package. Kann ich gut verstehen. BeautifulSoup ist denk ich gerade mit deshalb so beliebt. Einfach zu integrieren

[birkenfeld]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

[poker]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

Ganze Sätze Herr Birkenfeld! Also, was meinst du? Kann dir nicht folgen.

edit: typos

[gerold]

Ich dachte, das warst du...

Hallo!

Um das aufzuklären: Die Aussage "Klasse nicht für Namespace nutzen" habe ich von BlackJack aufgeschnappt. Und da er einer von denen ist deren Meinung bei mir zählt, suche ich nach Alternativen.

Ich muss aber auch zugeben, dass ich nicht mehr lange suchen werde. Ich habe etwas dagegen, eine feine Sache gegen etwas Umständlicheres ohne Mehrwert zu tauschen. Und eine kleine Klasse mit 30 Zeilen ist mir im Hauptprogramm lieber als in einer eigens dafür angelegten Datei. Noch dazu muss ich dann extra dafür ein Projekt in der IDE anlegen (um mehrere Dateien zu verwalten) und jedes mal das Modul öffnen, wenn ich nachsehen muss was sich darin befindet.

In dem Umfang, in dem ich normalerweise programmiere, hätte ich dann (ich habe nachgesehen...) Projekte mit zehn oder mehr Modulen, die jetzt in einem oder zwei Modulen schön übersichtlich funktionieren.

Es geht mir nicht um die Verteilung der Programme. Das ist nie ein Problem gewesen. Ob ich jetzt eine oder mehrere Python-Dateien verteile, macht keinen Unterschied, da ich sowiso immer Bilder, INI-, Datenbank- und sonstige Dateien mit verteilen muss.

Es geht mir mehr um die Übersichtlichkeit. Und viele kleine Dateien halte ich für weniger übersichtlich als wenige größere Module in denen alles drinnen ist, was zusammen gehört. Das hängt aber sicher auch davon ab, welche IDE man zum Programmieren verwendet und was jemand glaubt, dass es zusammen gehört und was nicht.

lg
Gerold

[poker]

Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.

Ich dachte, das warst du...

Hmm, OK. Im kontext zu Gerold's lätzten Post wird's mir nun klar.

Ich wüste nicht, Birkenfeld, wo ich in diesem Forum hier die "reine" Lehre verbreiten würde? Bin ja noch nicht lange hier im Forum. Wenn du diesen Topic hier meinst, dann hast du schlicht und einfach entweder meine Posts nicht richtig oder alle gelesen, oder gar verstanden.

Der reihe nach:

Sa Sep 22, 2007 00:01:
Der post der die Ansichten von OOP beschreibt, ist nicht so gemeint gewesen, das es auch meiner vollen Meinung entspricht und ich es alls meine Aufgabe betrachte das zu verbreiten. Das sollte auch aus dem sechsten Absatz und den anderen Posts hervorgegangen sein.

Nächster Punkt im Kontext zu Sa Sep 22, 2007 00:01:
Besonders diese Zitate von mir sollten dir zu denken geben:

Meine Meinung resultiert nicht daraus das andere Leute mir sagen was richtig und falsch ist, sondern durch eigene Erfahrung!

Letztendlich ist die "reine" Lehre nur soviel Wert bis man auf deren Grenzen stößt, das aber in dem Fall halt nicht gegeben ist. Deshalb empfehlen wir dir auch de anderen Lösungen weil sie "sauberer" und "pythonischer" sind.

Auch kannst du den anderen Posts entnehmen, das ich zu den anderen Pattern geraten habe weil **miner** Erfahrung nach es besser "funktioniert" als wenn man eine classe mit statics nutzt um damit ein Singelton zu emulieren (Einige der nachteiel habe ich ja genannt).

Dazu muss man nur noch beachten (auch in den Poststs ersichtlich) das ich Gerold's Intention erst viel zu spät mitgekriegt habe Im ging es um ein ganz andere Problem als ich zu erst angenommen habe. Und klar, dafür sind weder Module, Borg oder Singelton zu gebrauchen.

Gerold sucht eigentlich nach einer möglichkeit in Python die äquivalent mit Rubys ``module`` ist: http://home.vrweb.de/~juergen.katins/ru ... dules.html

Klar kann man dafür auch einfach eine Klasse nutzen, aber **und** das ist der Punkt, es ist nicht sofort ersichtlich für einen was die Intention ist. Sprich: Wenn ich (und X**N andere) sehe das einer eine Klasse als Funktionssammlung nutzt, ist **mein** erster Gedanke: "Warum keine Module!?". Sprich, die Dogmatik greift da irgendwo **doch** indirekt da man mit ``class`` was andere assoziert als der Einsatzzweck für das man es dann noch gebrauchen könnte!

In diesem Kontext (Für den Gerold und sicher viele andere auch) das haben wollen würden, wäre ein ``namespace`` Super hilfreich. Damit würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!) Im übrigen würde **ich es auch** nicht schlecht finden, weil es eine zusätzliche neue Qualität der Strukturierung mitbringt die **erstmal** frei von jeder ``class`` behafteten Ideologie/Dogmatik (nenne es wie du wilst) ist .

Daher noch mal die Frage: Worum ging es dir bei deiner Ansage Birkenfeld? Für mich hinterlässt es eher den Nachgeschmack eines Bashings (Ohne dich jetzt der Trollerei bezichtigen zu wollen), den ich erkenne den Mehrwert deines postings nicht sondern eher ein implizierte leichte provokante Note!

mfg

EDIT:
Ich möchte gerne noch die ersten drei Absätze aus dem von mir verlinkten Link Zitieren:

Sobald Ihre Programme in Ruby größer und größer werden, werden Sie normalerweise bemerken, dass Sie wiederverwertbaren Code produzieren -- Bibliotheken mit ähnlichen Routinen, die allgemein anwendbar sind. Sie werden diesen Code in separaten Dateien abspeichern möchten, damit ihn auch andere Ruby-Programme verwenden können.

Dieser Code wird oft in Klassen organisiert sein, also werden Sie vermutlich eine Klasse (oder eine Reihe von Klassen, die in Beziehung zueinander stehen) in eine Datei stecken.

Manchmal kommt es jedoch vor, dass man Dinge gruppieren möchte, die normalerweise keine Klasse bilden.

Und ich denke damit steht Gerold nicht alleine da. In Ruby hat man das erkannt und deshalb gibt es dort ``module``. Da in Python Module anders definiert sind (Also lediglich dateien die selbst wider ein Objekt darstellen), würde da das von Gerold vorgeschlagenen ``namespace`` treffender sein -- Damit hätte man die gleiche Syntax und Semantik innerhalb eines Python Modules

[Leonidas]

In diesem Kontext (Für den Gerold und sicher viele andere auch) das haben wollen würden, wäre ein ``namespace`` Super hilfreich. Damit würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!) Im übrigen würde **ich es auch** nicht schlecht finden, weil es eine zusätzliche neue Qualität der Strukturierung mitbringt die **erstmal** frei von jeder ``class`` behafteten Ideologie/Dogmatik (nenne es wie du wilst) ist .

Soll das etwas zusammengefasst heißen: "birkenfeld, bitte implementiere das in Python 3.0?" Wenn ich mir das so überlege - ich selbst habe selbst mal überlegt so Funktionen zusammenzufassen, aber letztendlich fand ich dass der Vorteil den es bietet zu gering ist, als dass man da weitere Syntaxkonstrukte hinzufügen müsste. Die Lösung Module dynamisch zu erstellen macht das Programm zur Laufzeit übersichtlicher, allerdings den Quellcode komplexer. Außerdem heißt es doch "Flat is better than nested.".. andererseits aber auch "Namespaces are one honking great idea -- let's do more of those!". Der Zen hat also auch zwei Meinungen dazu.

Und ich denke damit steht Gerold nicht alleine da. In Ruby hat man das erkannt und deshalb gibt es dort ``module``. Da in Python Module anders definiert sind (Also lediglich dateien die selbst wider ein Objekt darstellen), würde da das von Gerold vorgeschlagenen ``namespace`` treffender sein -- Damit hätte man die gleiche Syntax und Semantik innerhalb eines Python Modules

Ich habe ja vorgeschlagen das in Python zu implementieren. Dann kann man damit auch testen, ob das überhaupt praktikabel ist und als Beispielimplementierung würde dass auch für einen etwaigen PEP handlich sein.

[poker]

Wenn ich mir das so überlege - ich selbst habe selbst mal überlegt so Funktionen zusammenzufassen, aber letztendlich fand ich dass der Vorteil den es bietet zu gering ist, als dass man da weitere Syntaxkonstrukte hinzufügen müsste.

Naja, das ganze über ``codecs`` zu realisieren halte ich dann auch wider für zu übertrieben. Besser direkt im Python core integrieren um keinerlei Overhead in kauf zunehmen. Aber als POC IMO gut geeignet um die Praktikabilität auszutesten.

Außerdem heißt es doch "Flat is better than nested.".. andererseits aber auch "Namespaces are one honking great idea -- let's do more of those!". Der Zen hat also auch zwei Meinungen dazu.

Stimmt, ganz so konsistent ist der Zen dann noch wider nicht

Ich habe ja vorgeschlagen das in Python zu implementieren. Dann kann man damit auch testen, ob das überhaupt praktikabel ist und als Beispielimplementierung würde dass auch für einen etwaigen PEP handlich sein.

Das wäre vielleicht garnicht so schlecht ein PEP mit nem POC zu eröffnen Den POC könnte man dann, wie von dir in einem der post hier im thread vorgeschlagen, mit ``codecs`` implementieren. Dann könnte man ein wenig rumspielen; aber eigentlich: In Ruby ist es ganz praktikabel und nützlich. Ich denke in Pyhton würde es daher auch funktionieren. Müsste man mal die pythonista abstimmen lassen ob die sowas gut finden würden.

[mitsuhiko]

Ich find zwar die Idee nach wie vor bescheuert, aber mit Metaklassen kann man sich damit wenigstens virtuelle Module bauen:

Code: Alles auswählen

import sys, types

class NamespaceType(type):
  def __new__(cls, name, bases, d):
    rv = type.__new__(cls, name, bases, d)
    if namespace is not None:
        rv = rv(rv.__name__)
        sys.modules['%s.%s' % (rv.__module__, rv.__name__)] = rv
    return rv

namespace = None
class namespace(types.ModuleType):
  __metaclass__ = NamespaceType

class foo(namespace):
  def blub(self):
    print "Ich bin ein Modul"

Wenn man das jetzt in blub.py speichert kann man sowas tun:

Code: Alles auswählen

import blub
blub.foo.blub()

Oder halt auch

Code: Alles auswählen

from blub.foo import blub
blub()

//EDIT: Und Gott sei Dank haben wir nicht das Ruby Modulsystem, glaubt mir, das wollt ihr nicht

[poker]

Ich find zwar die Idee nach wie vor bescheuert, aber mit Metaklassen kann man sich damit wenigstens virtuelle Module bauen:

Code: Alles auswählen

import sys, types

class NamespaceType(type):
  def __new__(cls, name, bases, d):
    rv = type.__new__(cls, name, bases, d)
    if namespace is not None:
        rv = rv(rv.__name__)
        sys.modules['%s.%s' % (rv.__module__, rv.__name__)] = rv
    return rv

namespace = None
class namespace(types.ModuleType):
  __metaclass__ = NamespaceType

class foo(namespace):
  def blub(self):
    print "Ich bin ein Modul"

Wenn man das jetzt in blub.py speichert kann man sowas tun:

Code: Alles auswählen

import blub
blub.foo.blub()

Oder halt auch

Code: Alles auswählen

from blub.foo import blub
blub()

Sorry wenn das jetzt pampig rüberkommt aber irgendwie werde ich das Gefühl nicht los das hier einige e die Posts nicht richtig lesen!
Dan zitiere ich mich mal selber:

Klar kann man dafür auch einfach eine Klasse nutzen, aber **und** das ist der Punkt, es ist nicht sofort ersichtlich für einen was die Intention ist. Sprich: Wenn ich (und X**N andere) sehe das einer eine Klasse als Funktionssammlung nutzt, ist **mein** erster Gedanke: "Warum keine Module!?". Sprich, die Dogmatik greift da irgendwo **doch** indirekt da man mit ``class`` was andere assoziert als der Einsatzzweck für das man es dann noch gebrauchen könnte!

In diesem Kontext (Für den Gerold und sicher viele andere auch) das haben wollen würden, wäre ein ``namespace`` Super hilfreich. Damit würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!) Im übrigen würde **ich es auch** nicht schlecht finden, weil es eine zusätzliche neue Qualität der Strukturierung mitbringt die **erstmal** frei von jeder ``class`` behafteten Ideologie/Dogmatik (nenne es wie du wilst) ist .

Und nichts anderes macht dein Beispiel auch. Ok, die Metaclass erzeugt das Pseudo Module und trägt es in ``sys.modules`` ein, aber an dem eigentlichen Akt der Benutzung (``class``) ändert das nichts.
Der Punkt ist durch die Einführung von ``namespace`` ...

würde es erst gar nicht zu Ideologischen Diskussionen kommen, weil man schlicht und einfach weiß ``class`` != ``namespace`` (Auch wenn die Semantik vielleicht die gleiche bleibt!)

. Punkt.

[poker]

//EDIT: Und Gott sei Dank haben wir nicht das Ruby Modulsystem, glaubt mir, das wollt ihr nicht

Nein, Rubys ``module`` (Wenn du das jetzt meinst) hat rein garnichts mit Pythons Modulen zu tun. In Ruby könne mit ``module`` eingeführte namespaces beliebig oft in einer Datei vorkommen und werden sehr oft auch zu Strukturierung genutzt. Gerold und viele aus der Ruby Welt scheinen das doch gebrauchen zu können. Ich erkenne auch kein Nachteil davon, nur vorteile.

EDIT3: In Ruby ist eine Datei mit Ruby Code kein Modu,l wie es in Python der Fall ist! Das muss man unterscheiden (Falls du das jetzt meintest).

[gerold]

Code: Alles auswählen

import blub
blub.foo.blub()

[...]
Oder halt auch

Code: Alles auswählen

from blub.foo import blub
blub()

Hallo blackbird!

Ich glaube, das hast du falsch verstanden. Es geht nicht darum, auf biegen und brechen ein "Modul" zu erzeugen, sondern um die optische Gruppierung von zusammen gehörenden Codeteilen.

Es geht um die Optik und darum, dass es manchen nicht passt, wenn man Funktionen, die zusammen gehören, einfach in Klassen rein packt.

Mein Vorschlag wäre also:

Code: Alles auswählen

namespace Foo:
    def bar():
        return "bar"
    def spam():
        return "spam"

print Foo.bar()
print Foo.spam()

Anstelle von:

Code: Alles auswählen

class Foo:
    def bar(self):
        return "bar"
    def spam(self):
        return "spam"

foo = Foo()
print foo.bar()
print foo.spam()

Das was im Beispiel der "namespace Foo" ist, würde man normalerweise in ein Modul auslagern, damit man wie im Beispiel darauf zugreifen kann. Aber oft möchte man so etwas nur für ein paar Zeilen Code verwenden. Wenn ich diese Codezeilen jedes Mal in ein eigenes Modul auslagere, dann würde der Quellcode unübersichtlich werden....
Auslagern macht natürlich Sinn, wenn der Code auch von anderen Modulen importiert werden würde. Aber das ist bei vielen kleinen Programmen von vorneherein komplett ausgeschlossen. Oft kommen so sogar zirkuläre Referenzen ins Spiel, die das Programm anfälliger machen. -- Mehrfache Importe, die eigentlich gar nicht nötig wären, da ein Modul ohne das andere Modul sowiso nicht funktioniert. Das Hauptmodul importiert das Log-Modul. Das Log-Modul importiert das Hauptmodul. -- Da stellt sich dann die Frage, warum man das übehaupt so stark voneinander getrennt hat.
Ein Namespace innerhalb eines Modules würde diese "Probleme" gar nicht erst entstehen lassen. Und wenn man später doch merkt, dass man den Namespace lieber in ein Modul ausagern würde, dann verschiebt man den Code des Namespaces in ein neues Modul und importiert im Hauptmodul das neue Modul. Fertig!

Noch mal zur Klarstellung: Es geht nicht darum, etwas logisch in ein Modul oder einen Namespace zu verschieben, sondern darum, Code der zusammen gehört auch optisch zu kennzeichnen. Und das ohne viele kleine Module erstellen zu müssen.

Das geht natürlich heute auch schon mit Klassen. Aber das stößt manch Anderen sauer hoch. -- Aus ideologischen Gründen. Und ich habe auch eine Ideologie der ich nachstrebe. Die Optik des Quellcodes muss vom Auge leicht scannbar sein. Ich will den Quellcode verstehen, noch bevor ich ihn von vorne bis hinten durchgelesen habe. Einfach durch "darüberlesen". Das erleichtert meine Arbeit und meine Art zu denken enorm.

lg
Gerold