Python dynamic attribute creation
in [Python]
|
From: Stephen Hansen on 28 Jun 2010 11:41 On 6/28/10 8:27 AM, Aahz wrote: > In article<4c285e7c$0$17371$426a74cc(a)news.free.fr>, > Bruno Desthuilliers<bruno.42.desthuilliers(a)websiteburo.invalid> wrote: >> Aahz a �crit : >>> In article<4c2747c1$0$4545$426a74cc(a)news.free.fr>, >>> Bruno Desthuilliers<bdesth.quelquechose(a)free.quelquepart.fr> wrote: >>>> >>>> Python has no pretention at "elegance". >>> >>> That's not true at all. More precisely, I would agree with you if the >>> emphasis is on "pretention" but not if the emphasis is on elegance; >> >> Python Zen, #9 (or #8 if you're a TrueHacker !-)) > > ...and this implies that Python has no focus on elegance because...? Um, yeah, seriously :) #1-#7 seem to all be quite about not just elegance, but how to define it :) -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Alexander Kapps on 28 Jun 2010 15:09 Bruno Desthuilliers wrote: > Alexander Kapps a écrit : > (snip) >> While I personally don't agree with this proposal (but I understand >> why some people might want it), I can see a reason. >> >> When disallowing direct attribute creation, those typos that seem to >> catch newcommers won't happen anymore. What I mean is this: >> >> class Foo(object): >> def __init__(self): >> self.somearg = 0 >> >> f = Foo() >> f.soemarg = 42 >> >> ---^ There, typo, but still working >> >> It's something like a custom __setattr__ that errors out when trying >> to assign to an attribute that doesn't exists, > > Chicken and egg problem, really : f.__dict__['somearg'] doesn't exists > until "self.somearg = 0" is executed. > > The "problem" is that Python's methods are only thin wrapper around > functions (cf http://wiki.python.org/moin/FromFunctionToMethod) so > there's no difference between "self.somearg = 0" in Foo.__init__ and > "f.somearg = 42". > > IOW, there's no way to implement this proposal without completely > changing Python's object model. I must be missing something. Can you please explain why the whole object model would need to change? This seems to work quite well: class TypoProtection(object): def __init__(self): self.foo = 42 self.bar = 24 def _setattr(self, name, value): if name in self.__dict__: self.__dict__[name] = value else: raise AttributeError, "%s has no '%s' attribute" \ % (self.__class__, name) self.__class__.__setattr__ = _setattr t = TypoProtection() t.foo = "spam" t.bar = "ham" t.parrot = "dead" Traceback (most recent call last): File "typo.py", line 20, in <module> t.parrot = "dead" File "typo.py", line 10, in _setattr raise AttributeError, "%s has no '%s' attribute" % (self.__class__, name AttributeError: <class '__main__.TypoProtection'> has no 'parrot' attribute So, IIUC, all what would need to be done is to add an implicit __setattr__ at the end of __init__ . (Just want to understand, still not advocating this proposal)
From: Alexander Kapps on 28 Jun 2010 15:23 Alexander Kapps wrote: > Bruno Desthuilliers wrote: >> Alexander Kapps a écrit : >> (snip) >>> While I personally don't agree with this proposal (but I understand >>> why some people might want it), I can see a reason. >>> >>> When disallowing direct attribute creation, those typos that seem to >>> catch newcommers won't happen anymore. What I mean is this: >>> >>> class Foo(object): >>> def __init__(self): >>> self.somearg = 0 >>> >>> f = Foo() >>> f.soemarg = 42 >>> >>> ---^ There, typo, but still working >>> >>> It's something like a custom __setattr__ that errors out when trying >>> to assign to an attribute that doesn't exists, >> >> Chicken and egg problem, really : f.__dict__['somearg'] doesn't >> exists until "self.somearg = 0" is executed. >> >> The "problem" is that Python's methods are only thin wrapper around >> functions (cf http://wiki.python.org/moin/FromFunctionToMethod) so >> there's no difference between "self.somearg = 0" in Foo.__init__ and >> "f.somearg = 42". >> >> IOW, there's no way to implement this proposal without completely >> changing Python's object model. > > I must be missing something. Can you please explain why the whole object > model would need to change? UHHM! Forget it. This of course doesn't work with setattr too. My stupidness. :-(
From: Stephen Hansen on 28 Jun 2010 15:30 On 6/28/10 12:09 PM, Alexander Kapps wrote: > This seems to work quite well: > > class TypoProtection(object): > def __init__(self): > self.foo = 42 > self.bar = 24 > > def _setattr(self, name, value): > if name in self.__dict__: > self.__dict__[name] = value > else: > raise AttributeError, "%s has no '%s' attribute" \ > % (self.__class__, name) > > > self.__class__.__setattr__ = _setattr This will only work the first time you make an instance: thereafter, __setattr__ will be on the class and future instances will refuse to allow the creation of "foo" and "bar", as they won't already exist in the new instance's dictionary. That said, you can certainly make a class that only allows pre-approved attributes and prevents the creation of on the fly ones. Something like (untested): class TypoProtection(object): ALLOWED_ATTRIBUTES = ["foo", "bar"] def __setattr__(self, key, value): if key not in TypoProtection.ALLOWED_ATTRIBUTES: raise AttribuetError("TypoProtection does not have %s attribute." % (key,)) return object.__setattr__(self, key, value) Now, I would very rarely *do* such a thing, but you *could* if you wanted to. (You achieve a similar effect by abusing __slots__) -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Michael Torrie on 28 Jun 2010 15:47
On 06/25/2010 09:39 PM, WANG Cong wrote: > Thanks, I have to admit that I know nothing about Smalltalk. If you know nothing about Smalltalk then you really aren't in a position to talk about what is and is not OOP. Smalltalk is one of the original OOP languages and purists define OOP as the model that Smalltalk implemented. In many ways Python is like Smalltalk. Certainly it's more like Smalltalk than Java or C++. Although Python has a few pieces of syntactic sugar that aren't truly OO, Python is much more OO than C++ or Java, for the reasons that others have already posted. Some of your "doubts" concerning Python and OOP stem directly from your exposure to Java and C++'s paradigms > Hmm, although this is off-topic, I am interested in this too. C++ does > have metaprogramming, but that is actually static metaprogramming (using > templates), not dynamic metaprogramming here. I am wondering if > efficiency is the only reason why C++ doesn't have dynamic > metaprogramming, since C++ is a static programming language I think if > this limits C++ to implement its dynamic metaprogramming actually... I don't think C++ has any syntactic support for dynamic metaprogramming, but I did read an article in Doctor Dobb's Journal that talked about dynamic inheritance in C++. The Boost library provides some static metaprogramming facilities for C++. |