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.).
Hallo poker!poker hat geschrieben: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.
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.
Ok, so mancher Logger kennt auch keine 
Jagerold hat geschrieben:Methoden, die nicht auf ein Attribut der Klasseninstanz zugreifen müssen, gehören nicht in eine Klasse.
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: Und durch die "Integrierung" von AOP haben die sich dann gänzlich von dem "Ideal" OOP entfernt.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 stuffMachbar 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).poker hat geschrieben: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.
Ich dachte, das warst du...poker hat geschrieben:Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.
Ganze Sätze Herr Birkenfeld!birkenfeld hat geschrieben:Ich dachte, das warst du...poker hat geschrieben:Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.
Also, was meinst du? Kann dir nicht folgen. Hallo!birkenfeld hat geschrieben:Ich dachte, das warst du...
Hmm, OK. Im kontext zu Gerold's lätzten Post wird's mir nun klar.birkenfeld hat geschrieben:Ich dachte, das warst du...poker hat geschrieben:Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.
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).poker hat geschrieben: Meine Meinung resultiert nicht daraus das andere Leute mir sagen was richtig und falsch ist, sondern durch eigene Erfahrung!poker hat geschrieben: 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.
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. 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 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 ModulesSobald 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.
Soll das etwas zusammengefasst heißen: "birkenfeld, bitte implementiere das in Python 3.0?"poker hat geschrieben: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!)
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.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 hat geschrieben: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
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.Leonidas hat geschrieben: 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.
Stimmt, ganz so konsistent ist der Zen dann noch wider nichtLeonidas hat geschrieben: 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.
Das wäre vielleicht garnicht so schlecht ein PEP mit nem POC zu eröffnenLeonidas hat geschrieben: 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.
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.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"Code: Alles auswählen
import blub
blub.foo.blub()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!blackbird hat geschrieben:Ich find zwar die Idee nach wie vor bescheuert, aber mit Metaklassen kann man sich damit wenigstens virtuelle Module bauen:
Wenn man das jetzt in blub.py speichert kann man sowas tun: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"Oder halt auchCode: Alles auswählen
import blub blub.foo.blub()Code: Alles auswählen
from blub.foo import blub blub()
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.poker hat geschrieben: 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!)
. Punkt.poker hat geschrieben: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!)
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.blackbird hat geschrieben: //EDIT: Und Gott sei Dank haben wir nicht das Ruby Modulsystem, glaubt mir, das wollt ihr nicht
Hallo blackbird!blackbird hat geschrieben:[...]Code: Alles auswählen
import blub blub.foo.blub()
Oder halt auchCode: Alles auswählen
from blub.foo import blub blub()
Code: Alles auswählen
namespace Foo:
def bar():
return "bar"
def spam():
return "spam"
print Foo.bar()
print Foo.spam()Code: Alles auswählen
class Foo:
def bar(self):
return "bar"
def spam(self):
return "spam"
foo = Foo()
print foo.bar()
print foo.spam()Ich zitiere dich:poker hat geschrieben:Ganze Sätze Herr Birkenfeld!birkenfeld hat geschrieben:Ich dachte, das warst du...poker hat geschrieben:Das ist da doch zuviel gehacke. Dann kann man auch gleich ``class`` als namespace Nutzen. Aber dan kommen die jenigen mit ihrer "reinen" Lehre.
Meiner Meinung sollte man Klassen nicht als Namensräume missbrauchen.
Nein. Ich meinte, dass du in Ruby nur einen Namespace hast und die Module einfach nur über den Constant-Lookup die Klassen suchen. Mit allen tollen Nebenwirkungen. Ist eigentlich JavaScript Module auf Drogenpoker hat geschrieben: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).
Hallo birkenfeld!birkenfeld hat geschrieben:
- Die ganze Thematik "ich brauche aber einen Namespace!!!1" kommt mir sowieso spanisch vor. Wenn du "a.b" willst, erstell dir ein Modul "a", und fertig. Ansonsten nimm "a_b" und gut is.
Code: Alles auswählen
class Foo:
def bar(self):
return "bar"
def spam(self):
return "spam"
foo = Foo()
print foo.bar()
print foo.spam()