Python dynamic attribute creation
in [Python]
|
From: Thomas Jollans on 26 Jun 2010 08:00 On 06/26/2010 05:39 AM, WANG Cong wrote: > On 06/26/10 00:11, Neil Hodgson <nyamatongwe+thunder(a)gmail.com> wrote: > >> WANG Cong: >> >>> 4) Also, this will _somewhat_ violate the OOP princples, in OOP, >>> this is and should be implemented by inherence. >> >> Most object oriented programming languages starting with Smalltalk >> have allowed adding attributes (addInstVarName) to classes at runtime. > > > Thanks, I have to admit that I know nothing about Smalltalk. > >>From what you are saying, Smalltalk picks a way similar to setattr() in > Python? Because you mentioned 'addInstVarName' which seems to be a > method or a builtin function. If so, that is my point, as I mentioned > earlier, switching to setattr() by default, instead of using assignments > by default. :) > >> Low level OOPLs like C++ and Delphi did not implement this for >> efficiency reasons. >> > > 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, Yes, it is. I'm not quite sure how far RTTI actually goes, but I know that performance is a key issue in the design of C++. If you have a look at the developments toward C++0x, you will see that many new features are being proposed - C++ is an expert's language, designed to give an expert the most powerful tool possible, with the restriction that no new feature may have a negative performance impact on an existing feature. Adding actual dynamism would have a massive impact on performance and is thus, for C++, not acceptable. > since C++ is a static programming language I think if > this limits C++ to implement its dynamic metaprogramming actually... > > Thanks. >
From: Alexander Kapps on 26 Jun 2010 12:01 Ixokai wrote: > In what possible way is: > > setattr(foo, 'new_attr', 'blah') > getattr(foo, 'new_attr') > delattr(foo, 'new_attr') > > Better then: > > foo.new_attr = 'blah' > foo.new_attr > del foo.new_attr > > I don't understand what your argument is or problem is with the regular > syntax, if you want to allow the former (all of which is currently > possible in Python if you prefer this style) but not the latter (all of > which also works, it just uses normal syntax as everyone would expect). > > Do you think it should be somehow "tricky" or "more difficult" to > dynamically modify an instance at runtime? For that to hold, you have to > provide some pretty compelling reasoning why dynamically modifying an > instance at runtime is Not Good. Only then is there a good reason to > make it more difficult. (Since Python doesn't really restrict things, > just makes certain rare things that are undesirable a little harder to do) > > --Stephen > 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, just as default behavior. Sure, unittest are the Right Way(tm) to handle this, but there is a learning curve for new programmers wrt unittest. And disallowing this, doesn't take away any dynamism since setattr and friends are still there. Anyway, since I do a lot interactive programming I don't want it. It would hinder me a lot.
From: Stephen Hansen on 26 Jun 2010 13:10 On 6/26/10 9:01 AM, Alexander Kapps wrote: > 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: I get where you're coming from, but I don't see why "attributes" should get such special typo-protection when locals and any other names shouldn't. I see it as an extension of "Special cases aren't special enough to break the rules." -- and here I think the OP and I disagree most strongly. This characterization of adding attributes to an object as something "else", some special kind of activity called "metaprogramming" I think I reject outright, whereas I believe -- though I do not claim to speak for him/her -- the OP's position is that using 'syntax' to add attributes is actually a special case/activity. I consider it the standard, normal behavior. If this is how I create a local variable: x = 1 And to read that variable, I simply refer to it as "x", and if to read a defined attribute from an object I do: a.x Then, to me, the way in which I would set a new variable on that object is clearly: a.x = 1 I don't see why Python should special case setting an attribute on an object to be so wildly different then setting a local variable (or global, or anything else) as to require a special function call. The activity of "adding an attribute to an object" is no more special, IMHO, then "adding a variable to the local scope". Now, true: I fully acknowledge that if you're in an OOP-mindset and you're choosing to use a certain style of programming (and one I frequently indulge in), then you may /choose/ to treat certain objects as special, as being more firmly structured, as having a formal definition. In that situation, certainly: adding an attribute on the fly to that formal definition seems entirely strange and special of an activity. But that's only because you *chose* to *see* and *use* the object that way. The "special"ness of the activity is entirely in your head, and to Python, its an entirely normal event. Python lets you associate significance with normal events so you can get things done. But its just plodding along not really drinking whatever kool-aid you are, though its happy you like your flavor and is entirely content with letting you think its playing ball with you on that. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Alexander Kapps on 26 Jun 2010 17:59 Stephen Hansen wrote: > On 6/26/10 9:01 AM, Alexander Kapps wrote: >> 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: > > I get where you're coming from, but I don't see why "attributes" should > get such special typo-protection when locals and any other names shouldn't. Well, I would sympathize with an attempt to add some kind of typo protection. Not build into the language, but I dream about a command line switch that invokes a test like pylint/PyChecker. I wish any of those would enter the standard distribution. > I see it as an extension of "Special cases aren't special enough to > break the rules." -- and here I think the OP and I disagree most strongly. > > This characterization of adding attributes to an object as something > "else", some special kind of activity called "metaprogramming" I think I > reject outright, whereas I believe -- though I do not claim to speak for > him/her -- the OP's position is that using 'syntax' to add attributes is > actually a special case/activity. > > I consider it the standard, normal behavior. > > If this is how I create a local variable: > x = 1 > > And to read that variable, I simply refer to it as "x", and if to read a > defined attribute from an object I do: > a.x > > Then, to me, the way in which I would set a new variable on that object > is clearly: > a.x = 1 > > I don't see why Python should special case setting an attribute on an > object to be so wildly different then setting a local variable (or > global, or anything else) as to require a special function call. The > activity of "adding an attribute to an object" is no more special, IMHO, > then "adding a variable to the local scope". I fully agree with everything so far. As I said, i don't support this proposal, just that I can see a reason why some people might want this. I do this type of dynamic attribute addition (both data and methods) all day in my interactive sessions, which are a large part of my Python activity. > Now, true: I fully acknowledge that if you're in an OOP-mindset and > you're choosing to use a certain style of programming (and one I > frequently indulge in), then you may /choose/ to treat certain objects > as special, as being more firmly structured, as having a formal definition. > > In that situation, certainly: adding an attribute on the fly to that > formal definition seems entirely strange and special of an activity. But > that's only because you *chose* to *see* and *use* the object that way. > The "special"ness of the activity is entirely in your head, and to > Python, its an entirely normal event. That was an interesting insight, thank you for this. While I actually know all this, I indeed still seem to sometimes treat objects as "fixed-once-defined-and-created" entities. I just grep'ed all my code repository and found that I almost never do any on-the-fly attribute addition (totally contrary to my interactive work) You may have just opened the door the my next level of Python OO understanding. Thank you! :-) > Python lets you associate significance with normal events so you can get > things done. But its just plodding along not really drinking whatever > kool-aid you are, though its happy you like your flavor and is entirely > content with letting you think its playing ball with you on that.
From: Steven D'Aprano on 26 Jun 2010 21:06
On Sat, 26 Jun 2010 10:10:39 -0700, Stephen Hansen wrote: > This characterization of adding attributes to an object as something > "else", some special kind of activity called "metaprogramming" I think I > reject outright, whereas I believe -- though I do not claim to speak for > him/her -- the OP's position is that using 'syntax' to add attributes is > actually a special case/activity. > > I consider it the standard, normal behavior. +1 [...] > In that situation, certainly: adding an attribute on the fly to that > formal definition seems entirely strange and special of an activity. But > that's only because you *chose* to *see* and *use* the object that way. > The "special"ness of the activity is entirely in your head, and to > Python, its an entirely normal event. Exactly. Things which other languages make scary and mysterious "metaprogramming" are, in Python, normal and ordinary programming. It doesn't seem to do us any harm. In fairness, the reason the other languages do so is probably so that the compiler can make optimizations leading to faster code, which is why CPython is a fairly plodding implementation. But that's due to the conservativeness of CPython: Unladen Swallow is faster, and PyPI is faster still, and the PyPI people expect to eventually be competitive with C for speed. > Python lets you associate significance with normal events so you can get > things done. But its just plodding along not really drinking whatever > kool-aid you are, though its happy you like your flavor and is entirely > content with letting you think its playing ball with you on that. Nice :) -- Steven |