Python dynamic attribute creation
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: 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.) 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++. 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. 4) Also, this will _somewhat_ violate the OOP princples, in OOP, this is and should be implemented by inherence. 5) This could hide errors silently, for example, when I do: >>>test.typo = "blah" I am expecting Python will compllain that "Hey! You have a typo in the attribute name!". Also, this could make code worse to read, if I add a new attribute in one place, and add another one in the another place, and so on, what attributes the hell do I have finally?! I know someone will say you can change this by overriding the __set_attr__ function, like Recipe 6.3 in Python Cookbook. However, this is not default. In my points of view, a better design should be: 1) Disallow dynamic attribute creations by assignments _by default_, thus I expect an error when I do: >>> foo.new_attr = "blah" AttributeError: by default. 2) For people who want to add a new attribute at runtime, but not to override __set_attr__, he/she should switch to: >>> setattr(foo, "new_attr", "blah") This will be more like doing metaprogramming rather than non-meta programming, at least more obvious than using an assignment. 3) Allow users who don't like this to change by __set_attr__, of course. Someone argued with me that Python is a dynamic language, allowing this is natural. True, I do understand that attributes in Python are stored in an internal dictionary (__dict__), allowing assignments to an non-existing key is natural. However, this will be a little different when we talk about classes attributes, simple assignments could have side-effects, besides the traditional assignments effect, like in C, that is, creating a new attribute silently. So even from a view of beauty, this is not a good design. I hope someone could teach me more about why Python design it like it is. Any reply is more than welcome. Thanks for your time! -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 17:25, Steven D'Aprano wrote: > On Fri, 25 Jun 2010 14:15:12 +0100, WANG Cong wrote: > >> 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: >> >> 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. > (Thanks for your reply.) > Yes, isn't it wonderful? In other languages, metaprogramming is deepest > black magic, or even completely impossible. In Python it is so easy that > anyone can do it, and it is something beginners learn. > The point is why making metaprogramming easy is wonderful? AND, even if it were wonderful, why only this one, i.e. creating attributes by assignments, not other things? In my points of view, a programming language is wonderful only when it is designed so, there is no other things like this one in Python, AFAIK, are as simple as this one, thus making this one really odd to me. :-) > >> 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++. > > Why should it be? It is, if you consider other things of metaprogramming in Python. For example, deleting an attribute. > > >> 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. > > Why do you care if you are doing metaprogramming? Perhaps other languages > make it seem difficult and scary, but in Python it is not. It is simple > and easy. > I do care, programming for a class is quite different from programming for a non-class, even from a historical reason. They sit in different levels of programming. > >> 4) Also, this will _somewhat_ violate the OOP princples, in OOP, this is >> and should be implemented by inherence. > > Perhaps, and perhaps not. But Python has never pretended to slavishly > follow OOP "principles". Python does what works, not necessarily what is > a "pure" design. Python has functional programming, procedural > programming, and OO programming, and happily mixes them all together. > "Happily mixes them all together" doesn't mean it is elegant. :) > >> 5) This could hide errors silently, for example, when I do: >> >>>>>test.typo = "blah" > > Yes, that is one downside to Python's dynamicism. The solutions are: > > * Unit tests, unit tests, unit tests. Then more unit tests. > (You're writing them anyway, aren't you?) > * Run PyChecker or PyLint to check the source code for errors. > * Don't make typos. *smiles* > Well, I am talking in the language design level, if we could solve this problem in the language design level, why do we need to bother these things? > >> I am expecting Python will compllain that "Hey! You have a typo in the >> attribute name!". Also, this could make code worse to read, if I add a >> new attribute in one place, and add another one in the another place, >> and so on, what attributes the hell do I have finally?! > > Then don't do that. > Yeah, "don't do that" is one thing, "Python allows to do that" is another thing. > >> I know someone will say you can change this by overriding the >> __set_attr__ function, like Recipe 6.3 in Python Cookbook. However, this >> is not default. In my points of view, a better design should be: >> >> 1) Disallow dynamic attribute creations by assignments _by default_, > > There are many languages that do that. Python is not one of them. Python > is *designed* to be a dynamic language. If you don't like dynamic > languages, then you have many, many, many other choices. Perhaps such a > language is better for *you*. Perhaps such non-dynamic languages are > better for huge applications written by thousands of developers. But > Python is designed to be a rapid prototyping language, and as such, > dynamicism is a feature, not a bug. Such as? As I said in the previous email, this is not so much related with dynamic programmin or not. Using 'setattr()' could also prove Python is a dynamic programming, but Python doesn't choose this by default. Thanks! -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 15:34, Bruno Desthuilliers 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 14:31, Richard Thomas wrote: > > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/26/10 03:31, Carl Banks wrote: > On Jun 25, 6:15 am, WANG Cong wrote: >> 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. > [snip points] > > > I understand you and think your proposal is reasonable. I know a few > people who use Python who would agree with you, and even go farther. > > You did well to propose not banning attributes per se, but making it > harder to set them. Python isn't really in the business of making > questionable things impossible (there are occasions where it does, > like killing threads), but it is in the business of making things that > are questionable enough harder. What you propose is reasonable under > Python's design principles (provided that initializer functions were > exempted), and if Python had been designed as you propose, I don't > think it would have suffered that much. > Thanks much for encouraging me! This makes me feeling less guilty. ;-) > Here's the thing: Python doesn't consider creating dynamic attributes > to be questionable. Python doesn't merely allow for dynamicism, it > encourages it. And encouraging something means to make it simple. > 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. > I know you won't agree with this, and I'm not trying to convince you > or argue with you. I'm just telling you why it's like that. > > I will also tell you that claims like "it's doesn't use good OOP > principles" or "C++ does it that way" carry almost no credit. How C++ > does something is a suggestion, nothing more. > In fact I wanted to avoid comparing Python with C++. :) When I talked about OOP, it is general OOP, not related with any concrete programming languages. -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/26/10 00:11, Neil Hodgson 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 19:38, Ethan Furman wrote: > WANG Cong wrote: >> On 06/25/10 15:34, Bruno Desthuilliers >> 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 "", line 1, in > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 22:11, Mark Lawrence wrote: > On 25/06/2010 19:23, WANG Cong wrote: >> On 06/25/10 14:31, Richard Thomas wrote: >> >> >> >>> >>> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 20:22, Ian Kelly wrote: > On Fri, Jun 25, 2010 at 12:51 PM, Stephen Hansen > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/29/10 17:48, Andre Alexander Bell 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". >> 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. > 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. > >> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/27/10 12:01, Carl Banks wrote: > On Jun 25, 8:24 pm, WANG Cong 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/30/10 01:25, Ethan Furman wrote: >> 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. > > Setattr and friends exist to work with dynamic attributes. > Yeah, my point is why setattr() for dynamic attributes while assignments for static attributes? Why not unify them? > "The Perfect Language" does not exist, and never will. I'm not even > sure it could exist for a single person, let alone a group of people > with disparate needs, patterns of thought, etc. > Agreed, but at least, the reason why I am being against so many people here is also trying to make Python be more perfect with my understanding. Thanks! -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/30/10 01:20, Stephen Hansen wrote: >> 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. > > What does perfection have to do with anything? Python does not strive > for perfection. More then that, it rejects the entire idea of > perfection when it gets in the way of simply solving problems in an > easy, clean, readable, and reliable way. "Practicality beats purity". > I don't quite understand the spirit behind. IMHO, being purity should not harm the practicality, they are harmonious. :) > PEP 363 proposes adding new syntax: for new syntax to be accepted into > the language one must meet a *very* high bar. One must show a clear, > compelling reason why this new mental burden is worth increasing the > complexity of the language. > > Syntax won't get added to make the language more "perfect" to some > ideals (especially not ideals to some paradigm like OOP, as opposed to > its own internal ideals of readability, ease and practicality). > > Syntax is a burden. Every change in syntax, every addition in syntax, > requires everyone's to mental investment to increase: it costs more > mental energy to use the language, to fully understand it, then it did > before. > But how could the syntax could be a burden? It is easy to understand. And the reason why needs it is also clear, making class attributes more like a dictionary, isn't this why people insists we should have dynamic attribute creation via assigments? This seems to be unfair. :) > > Is Python perhaps less perfect, pure, with that addition to the > language denied? > > Who cares? Perfection is what the Borg* worship, I like understandable. :) Well, using setattr() rather than trivial assignments is also understandable, in fact, for me the former is even more understandable, it shows more clearly when I am adding a new attribute, I am programming classes, not non-classes. -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 07/01/10 13:49, Stephen Hansen wrote: Hi, Stephen, >> >> It may not be "the" primary concern, but elegance certainly is *a* >> primary concern. > > I concur. > > Its not explicitly stated, but it is the Zen 0. This is further > supported by its implied presence in many of the Axioms and Truths of > the Bots. > > "Beautiful is better then ugly"; and then the praise of the explicit, > of simplicity, of readability. > > Elegance is a prime concern of Python, as it is the natural result of > the Doctrines of Pythonicity. It may not be stated as a rule, but it a > the reward that we are given for following the path of enlightenment. Isn't elegance somewhat equalent to perfection? IMHO, if a language is perfect, it is elegant. However, in the other sub-thread, you seem to be against being perfect for Python. :) -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/27/10 09:06, Steven D'Aprano wrote: >> 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. > As long as setattr() exists in Python, that will be not so ordinary. :) -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/28/10 17:43, Bruno Desthuilliers wrote: > Carl Banks a écrit : >> On Jun 27, 3:49 am, Bruno Desthuilliers >> wrote: >>> WANG Cong a écrit : >>> >>>> On 06/26/10 00:11, Neil Hodgson 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. >>> Then you really don't know much about OO. >> >> I don't really know much about Smalltalk either. >> > > Duh. I cancelled this totally stupid and useless post a couple seconds > after hitting the send button, but still too late :( > > So first let me present my apologies to WANG Cong and everyone else, > this was a crude, arrogant and totally stupid thing to say, and I > should know better. Sorry. > No problem. :) > Now on why I first wrote this (warning : personal opinions ahead): > > "object" started with Simula, but objects in Simula are mostly > glorified ADTs with type-based "polymorphic" dispatch. Smalltalk (and > all it's environment) got _way_ further by turning this into a > coherent whole by introducing messages (which are more than just > type-based polymorphic dispatch - Smalltalk's messages are objects > themselves) and "code blocks" - as the only mean to control "flow". I > believe that Smalltalk is (so far) the only "OO" language that was > innovative enough to really escape from good old procedural > programming, and as such possibly the only "True" OOPL. > > Now for various reasons (including implementation issues and > conservatism), it happened that the Simula approach to OO became the > mainstream with languages like C++ then Java, and that most of "OO" > litterature - "OOP principles", golden rules etc - is about this > somehow very restricted approach, so people being taught "OO" that way > have a very restricted - and incomplete - vision of what OO is really > about. That was how I was taught OO, and I always felt that there was > something wrong, inconsistant or missing. > > Studying Smalltalk (however briefly) was for me a real "AHA", > mind-opening moment - suddenly OO made sense as this coherent, > comprehensive and innovative approach to programming I so far failed > to find in Java or C++. > > Now I don't mean one has to master Smalltalk to be allowed to talk > about OO, nor that OO can't exist outside Smalltak (Python being IMHO > another exemple of an interesting and mostly coherent object system, > even if doesn't go as far as Smalltalk do), but - pardon me if this > seems arrogant (and please correct me if it really is) - I can't help > thinking that one cannot really understand OO whithout at least a > brief study of Smalltalk (and - once again - a full Smalltalk > environment, as Smalltalk the language is only one part of the 'full' > object system). > This sounds really cool, I think I should find some time to learn Smalltalk, even only considering historic reasons. Thanks for sharing your Smalltalk learning experience with us! -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 07/01/10 22:53, Stephen Hansen wrote: > > One uses assignment syntax when the name of the attribute they are > setting is known at the time when one writes the code. > > One uses the setattr function when the name of the attribute is not > known until runtime. > > The difference has *nothing at all* to do with "programming classes" > or "dynamic" vs "static". > This is exactly what I am thinking. What we differ is that if using both assignment syntax and setattr() builtin function is a good design. You think the current design which lets them co-exist is more understandable, while I think this is less perfect and then not that more understandable. :) "Understandable" is hard to define, it differs so much from person to person. "Perfect" is a strong sense for which I enjoy programming and learn programming languages. Thanks much for your detailed answers, I like discussing this with you! -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 07/01/10 23:19, Stephen Hansen wrote: >> >> As long as setattr() exists in Python, that will be not so ordinary. :) > > setattr is perfectly ordinary. If you think setattr() is as ordinary as a trivial assignment, I will argue with you, this is personal taste. However, I think setattr() is a builtin function, using it exposes the *magic* of metaprogramming (or class-programming, if more correct) at a first glance. -- Live like a child, think like the god. -- http://mail.python.org/mailman/listinfo/python-list
