Python dynamic attribute creation
in [Python]
|
From: Andre Alexander Bell on 29 Jun 2010 05:48 On 06/25/2010 03:15 PM, WANG Cong wrote: > 1) Modifying a class attribute is metaprogramming, and this is modifying > a class, i.e. adding a new attribute to it, thus this should belong > to metaprogramming. (I know, strictly speaking, maybe my definition of > "metaprogramming" here is incorrect, I _do_ welcome someone could > correct me if I am really wrong, but that is not the main point here, > please don't go off-topic.) We should define meta programming a little more. First attempt: Programming is the art of writing down instructions such that when executed accordingly will do what has been pre-specified. Meta programming is the art of writing down instructions such that when executed accordingly will program instructions that when executed accordingly will do what has been pre-specified. >From this definition I would argue that a dynamic attribute assignement is _not_ meta programming. It is just modifying an object. > 2) Metaprogramming should be distinguished with non-meta programming, > like templates in C++, it is obvious to see if you are using template > metaprogramming in C++. In my opinion meta programming is programming. It's just changing the view a little bit such that the program itself is nothing but data. > 3) Thus, allowing dynamic attribute creation by assignment _by default_ > is not a good design for me. It is not obvious at all to see if I am > doing metaprogramming at a first glance. As said previously I don't think one should differentiate between meta programming and programming within the language, since the former is nothing different than the latter. > 4) Also, this will _somewhat_ violate the OOP princples, in OOP, > this is and should be implemented by inherence. This is another point. Whether or not a language allows dynamic or static meta programming is completely orthogonal to whether or not it is a pure OO language. Python is not pure OO as others already did explain. You may still use it in pure OO style. If you would like to write your program in a complete OO style than adding an attribute (may as well be a method) from external class Sample(object): pass s = Sample() s.a = 1 has to be completely omitted. The same goes for adding attributes within some method of that particular class. class Sample(object): def addsomething(self): self.a = 1 s = Sample() s.addsomething() This would have to be omitted as well. In a complete OO style _no_ further attributes or methods are allowed to be added beyond the declaration of the class. Where is this declaration in Python? You might argue it is the __init__ method and that only there attributes should be added. This is. however, only a convention in Python. Variable instantiation is dynamic in Python. That is the variable is declared upon assignment. If you fire up an interactive session and write a = 1 then this declares the variable a and assigns a value to that variable. > 5) This could hide errors silently, for example, when I do: > >>>> test.typooooo = "blah" Yes. Such a typo would not be detected. > 1) Disallow dynamic attribute creations by assignments _by default_, > thus I expect an error when I do: So far I only did tell you _how_ it is in Python. If I understand your question about the design of the language correctly than you would like Python to detect the typo. Let's for the moment assume that the declaration would be decoupled from assigning a value. The first thing that would have to change is that in a class declaration we would have to specify at least the names of the attributes and methods. E.g. class Sample(object): var a def __init__(self): self.a = 1 s = Sample() s.b = 1 -> Exception This however would furthermore change the way you would have to write a function and a method due to possible internal variables def somefunc(): var a var b a = 1 b = 2 return a+b As soon as you would need a variable you would always first have to declare that variable and then assign a value. Even on the interactive shell you would have to do so: >>> var a >>> a = 1 >>> b = 2 -> Exception Why would this declaration be necessary on the shell and in the function/method? Declaring a variable means adding that variable to the namespace, i.e. the underlying dictionary. There is one in each object, the locals() of a function or even the __dict__ of a module. The downside of this is that Python has no such thing as a variable without a value. Still you would need such a thing for this approach >>> var a >>> a -> should raise an variable 'unset' exception The underlying dictionary would need the ability to store keys (variable names) without values. This approach increases the code length considerably, just to catch the typos. Keep in mind that the module you are writing in is just an object as is any function or method. So using local variables therein you are doing exactly what you want to abandon from the OOP part. Regards Andre
From: WANG Cong on 29 Jun 2010 12:46 On 06/29/10 17:48, Andre Alexander Bell <post(a)andre-bell.de> wrote: > On 06/25/2010 03:15 PM, WANG Cong wrote: >> 1) Modifying a class attribute is metaprogramming, and this is modifying >> a class, i.e. adding a new attribute to it, thus this should belong >> to metaprogramming. (I know, strictly speaking, maybe my definition of >> "metaprogramming" here is incorrect, I _do_ welcome someone could >> correct me if I am really wrong, but that is not the main point here, >> please don't go off-topic.) > > We should define meta programming a little more. First attempt: > > Programming is the art of writing down instructions such that when > executed accordingly will do what has been pre-specified. > > Meta programming is the art of writing down instructions such that when > executed accordingly will program instructions that when executed > accordingly will do what has been pre-specified. > >>From this definition I would argue that a dynamic attribute assignement > is _not_ meta programming. It is just modifying an object. > Yeah, probably this is the correct and strict definition of "metaprogramming". Thanks for correction. However, as I said above, I just wanted to borrow the word "metaprogramming" to express my meaning. What I meant is actually programming classes, you can call it "class-programming" if not "metaprogramm". <snip> >> 3) Thus, allowing dynamic attribute creation by assignment _by default_ >> is not a good design for me. It is not obvious at all to see if I am >> doing metaprogramming at a first glance. > > As said previously I don't think one should differentiate between meta > programming and programming within the language, since the former is > nothing different than the latter. > If you check other programming language rather than Python, it is different. Even in Ruby which is also a dynamic language. <snip> > Python is not pure OO as others already did explain. You may still use > it in pure OO style. > Yeah, even C can also have some OO style. But that is not the point. <snip> > >> 1) Disallow dynamic attribute creations by assignments _by default_, >> thus I expect an error when I do: > > So far I only did tell you _how_ it is in Python. If I understand your > question about the design of the language correctly than you would like > Python to detect the typo. Let's for the moment assume that the > declaration would be decoupled from assigning a value. > Nope, I would like Python not to allow adding a new attribute via an assignment by default, detecting the typo is a side-effect. > The first thing that would have to change is that in a class declaration > we would have to specify at least the names of the attributes and > methods. E.g. > > class Sample(object): > var a > def __init__(self): > self.a = 1 > > s = Sample() > s.b = 1 > -> Exception > > This however would furthermore change the way you would have to write a > function and a method due to possible internal variables > > def somefunc(): > var a > var b > a = 1 > b = 2 > return a+b > > As soon as you would need a variable you would always first have to > declare that variable and then assign a value. > > Even on the interactive shell you would have to do so: > >>>> var a >>>> a = 1 >>>> b = 2 > -> Exception > > Why would this declaration be necessary on the shell and in the > function/method? Declaring a variable means adding that variable to the > namespace, i.e. the underlying dictionary. There is one in each object, > the locals() of a function or even the __dict__ of a module. > > The downside of this is that Python has no such thing as a variable > without a value. Still you would need such a thing for this approach > >>>> var a >>>> a > -> should raise an variable 'unset' exception > > The underlying dictionary would need the ability to store keys (variable > names) without values. > > This approach increases the code length considerably, just to catch the > typos. > > Keep in mind that the module you are writing in is just an object as is > any function or method. So using local variables therein you are doing > exactly what you want to abandon from the OOP part. > Hmm, this looks really appealing. But if so why setattr() still exists? What is it for if we can do the same thing via assignments? Also, in order to be perfect, Python should accept to add dynamic attributes dynamically, something like PEP 363. That doesn't happen. Thanks! -- Live like a child, think like the god.
From: WANG Cong on 29 Jun 2010 12:48 On 06/27/10 12:01, Carl Banks <pavlovevidence(a)gmail.com> wrote: > On Jun 25, 8:24 pm, WANG Cong <xiyou.wangc...(a)gmail.com> wrote: >> Understand, but please consider my proposal again, if we switched to: >> >> setattr(foo, 'new_attr', "blah") >> >> by default, isn't Python still dynamic as it is? (Please teach me if I >> am wrong here.) >> >> This why I said the questionable thing is not so much related with dynamic >> programming or not. > > Because it makes dynamicism harder to do. > > Like I said, Python's goal isn't simply to make dynamicism possible, > it's to make it easy. > > "foo.new_attr = 'blah'" is easier than using setattr. > I do agree it's easier, but why do we need this to be easy? This is really my question. Also, since it is easier, why not drop the harder one, setattr()? -- Live like a child, think like the god.
From: Chris Rebert on 29 Jun 2010 12:57 On Tue, Jun 29, 2010 at 9:48 AM, WANG Cong <xiyou.wangcong(a)gmail.com> wrote: > On 06/27/10 12:01, Carl Banks <pavlovevidence(a)gmail.com> wrote: >> On Jun 25, 8:24Â pm, WANG Cong <xiyou.wangc...(a)gmail.com> wrote: >>> Understand, but please consider my proposal again, if we switched to: >>> >>> setattr(foo, 'new_attr', "blah") >>> >>> by default, isn't Python still dynamic as it is? (Please teach me if I >>> am wrong here.) >>> >>> This why I said the questionable thing is not so much related with dynamic >>> programming or not. >> >> Because it makes dynamicism harder to do. >> >> Like I said, Python's goal isn't simply to make dynamicism possible, >> it's to make it easy. >> >> "foo.new_attr = 'blah'" is easier than using setattr. > > I do agree it's easier, but why do we need this to be easy? This is > really my question. Conversely: Why do we need to make it harder than necessary? > Also, since it is easier, why not drop the harder one, setattr()? Because there's no way to write the following without using setattr() or similar, aside from adding new syntax: attr_name = raw_input("Enter an identifier: ") setattr(x, attr_name, 42) Cheers, Chris -- http://blog.rebertia.com
From: Ethan Furman on 29 Jun 2010 13:17
WANG Cong wrote: > On 06/27/10 12:01, Carl Banks <pavlovevidence(a)gmail.com> wrote: > >> On Jun 25, 8:24 pm, WANG Cong <xiyou.wangc...(a)gmail.com> wrote: >>> Understand, but please consider my proposal again, if we switched to: >>> >>> setattr(foo, 'new_attr', "blah") >>> >>> by default, isn't Python still dynamic as it is? (Please teach me if I >>> am wrong here.) >>> >>> This why I said the questionable thing is not so much related with dynamic >>> programming or not. >> Because it makes dynamicism harder to do. >> >> Like I said, Python's goal isn't simply to make dynamicism possible, >> it's to make it easy. >> >> "foo.new_attr = 'blah'" is easier than using setattr. >> > > I do agree it's easier, but why do we need this to be easy? This is > really my question. To excerpt from http://www1.american.edu/cas/econ/faculty/isaac/choose_python.pdf <quote> Choose the simple over the complex, and the complex over the complicated. </quote> > Also, since it is easier, why not drop the harder one, setattr()? Because setattr and friends are needed when the variable names are constructed dynamically. ~Ethan~ |