Python dynamic attribute creation
in [Python]
|
From: WANG Cong on 25 Jun 2010 14:18 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... Using assignments to create an attribute hides metaprogramming behide, while using delattr() exposes it. Thanks! -- Live like a child, think like the god.
From: WANG Cong on 25 Jun 2010 14:23 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. -- Live like a child, think like the god.
From: Ethan Furman on 25 Jun 2010 14:38 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... ~Ethan~
From: Ian Kelly on 25 Jun 2010 15:22 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. 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.
From: Mark Lawrence on 25 Jun 2010 17:07
On 25/06/2010 19:03, WANG Cong wrote: [lots of snips] > > "Happily mixes them all together" doesn't mean it is elegant. :) Bollocks springs to my mind. :) Kindest regards. Mark Lawrence. |