Python dynamic attribute creation
in [Python]
|
From: WANG Cong on 25 Jun 2010 23:39 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, since C++ is a static programming language I think if this limits C++ to implement its dynamic metaprogramming actually... Thanks. -- Live like a child, think like the god.
From: WANG Cong on 25 Jun 2010 23:58 On 06/25/10 19:38, Ethan Furman <ethan(a)stoneleaf.us> wrote: > WANG Cong wrote: >> On 06/25/10 15:34, Bruno Desthuilliers <bruno.42.desthuilliers(a)websiteburo.invalid> wrote: >> >>> WANG Cong a écrit : >>>> Hi, list! >>>> >>>> I have a doubt about the design of dynamic attribute creation by >>>> assignments in Python. >>>> >>>> As we know, in Python, we are able to create a new attribute of >>>> a class dynamically by an assignment: >>>> >>>>>>> class test: pass >>>> ... >>>>>>> test.a = "hello" >>>>>>> test.a >>>> 'hello' >>>> >>>> However, I still don't get the points why Python designs it like this. >>>> >>>> My points are: >>>> >>> (snip) >>> >>> Python's classes are plain objects, and like any other object are >>> created at runtime. Having to special-case them would break the >>> simplicity and uniformity of Python for no good reason. Just like >>> there's no good reason to make setattr() working differently for class >>> and non-class objects. >>> >> >> For implementaiton, perhaps, but not for the language design, how could >> a language design be perfect if we can use setattr() like assignments >> while use other things, e.g. delattr(), not? Is there any way to express >> delattr() as simple as expressing setattr() with assignments? I doubt... > >>>> del test.a >>>> test.a > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > AttributeError: class test has no attribute 'a' > > Looks pretty simple to me... > Ah, thanks for teaching this! I should think out it. So, this is much related with the fact that Python treats class attributes as dictionary keys and their values as dictionary values, thus unifies with the operations of dictionary. But this is still questionable. Dictionary keys can be constants and variable values, I mean: >>> foo['constant'] = 'blah' >>> foo[foo['constant']] = 'blah' however, class attributes not, they are constants only _at least_ in simple assignments. I searched in google and found that Python already had a proposal for dynamic attribute names [1], but it is rejected (surprisingly!). Thus, for people who want to really dynamic attribute names, he/she has to switch to setattr(). Isn't this what I insist? :) 1. http://www.python.org/dev/peps/pep-0363/ -- Live like a child, think like the god.
From: WANG Cong on 26 Jun 2010 00:04 On 06/25/10 22:11, Mark Lawrence <breamoreboy(a)yahoo.co.uk> wrote: > On 25/06/2010 19:23, WANG Cong wrote: >> On 06/25/10 14:31, Richard Thomas<chardster(a)gmail.com> wrote: >> >> <snip> >> >>> >>> If you desperately want to limit the attribute assignments that can be >>> performed on an object you can set the __slots__ attribute of its >>> type. However, the Python ethos has always been to restrict as little >>> as necessary to provide the tools it needs. Performing additional >>> checks every time an attribute assignment is performed is completely >>> unnecessary. Remember that unlike C these checks would have to be >>> performed at run-time. >>> >> >> I don't care in which way I can limit this, I care why I should limit >> this by default, not vice versa? >> >> Yeah, I do understand this could be a performance issue, but comparing >> it with a language design issue, _I think_ the latter thing is much more >> important than the former one. >> > > Blimey, one minute we're talking about "Python dynamic attribute > creation", the next it's a performance issue. What do you want, blood > on it? > No, I want people to focus on the language design things, not on performance things. By talking about "Python dynamic attribute creation", I want to question the language design of Python in this point, actually. :) If someone still insists that this should be a performance thing more than language design thing, then I will give up because that is saying this language is not beautiful on this point. Thanks. -- Live like a child, think like the god.
From: WANG Cong on 26 Jun 2010 00:22 On 06/25/10 20:22, Ian Kelly <ian.g.kelly(a)gmail.com> wrote: > On Fri, Jun 25, 2010 at 12:51 PM, Stephen Hansen > <me+list/python(a)ixokai.io> wrote: >>> Using assignments to create an attribute hides metaprogramming behide, >>> while using delattr() exposes it. >> >> I don't understand what you're saying here either. > > I think he's saying that when an attribute exists in the class > dictionary, assigning that attribute to an instance obscures it, and > deleting that attribute from an instance exposes it. > > The point being, I guess, that when an assignment to an instance > attribute is performed in the code, it's not immediately obvious > whether that assignment is updating something already defined in the > class or creating something entirely new. Whereas deleting an > instance attribute always exposes whatever is already defined at the > class level. > Exactly. Sorry that I confused you. > I think the distinction is false, though, since deleting an instance > attribute says nothing about whether that attribute is defined at the > class level to begin with. As I replied in a previous email, this makes Python unify the operations on class attribute with the operations on trivial dictionaries, yes, this is good, but Python doesn't do enough, it doesn't go further to allow dyname attribute _names_ which could make dyname class attribute perfect. The PEP [1] is rejected for some reason that I don't know. 1. http://www.python.org/dev/peps/pep-0363/ Even if it did accept this, I still hold my points on whether this should be done by assignments by default. Thanks. -- Live like a child, think like the god.
From: Neil Hodgson on 26 Jun 2010 06:40
WANG Cong: > From what you are saying, Smalltalk picks a way similar to setattr() in > Python? addInstVarName is a method on ClassDescription objects. > 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. :) No, that was only part of the problems you enumerated. You want to easily distinguish adding instance variables (possibly also other things) since these are 'metaprogramming'. Now, once setattr is available it is possible to call setattr any place where a function can be called so you are not going to be able to determine whether any particular statement, including o.f=1 adds a new instance variable. You would have to change Python a lot more to be able to determine easily from inspection whether a given statement is 'metaprogramming'. The main problem I had was that you were saying that adding an instance variable is a special form of programming when its just an ordinary part of programming in most languages. > 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. C++ is still extremely limited. Can you show a C++ example where a metaprogram modifies an existing class to add an instance variable? Neil |