Python dynamic attribute creation
in [Python]
|
From: WANG Cong on 1 Jul 2010 10:44 On 07/01/10 13:49, Stephen Hansen <me+list/python(a)ixokai.io> 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.
From: Stephen Hansen on 1 Jul 2010 10:39 On 7/1/10 5:41 AM, Bruno Desthuilliers wrote: > Stephen Hansen a �crit : >> On 6/30/10 10:37 PM, Aahz wrote: >>> 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. >> > > "Elegance" (just like "beauty") is in the eyes of the beholder. > > Explicitness, simplicity and readability are indeed primary concerns in > Python's design, but "elegance" is not. Now you'll of course find Python > mostly elegant *if* you value expliciteness, simplicity and readability, > but that's only because your definition of "elegant" happens to match > Guido's. But see, here I disagree with you, because I do think beauty -- as seen by Guido -- and elegance -- as seen by Guido -- *are* a prime concern of Python's design. Sure, those are subjective things, and not everyone will have the absolute same opinion on them. But there is an overriding sense of style and taste (in terms of code) which went into the design of the language and remained through its evolution, that is a very real and important part of the language we have today. A big difference between those people who like and really enjoy using Python verses those who prefer other solutions does come down to a sense of taste and compatibility with the Guido's taste. Some people never get past the revulsion of 'self' and whitespace. Certainly: there's a lot *more* then just taste at issue (I don't mean to trivialize those who select other solutions for reasons of more substance then style), and some people can be fans even without fully embracing Guido's definition of beauty and elegance. > But please gentlemen, let's not fight on this. This no religion, there's > no dogma here, and no heretic to burn. The religious-speak was a joke :) I'm not sure I remember fighting though, either way. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Aahz on 1 Jul 2010 10:51 In article <mailman.2311.1277759128.32709.python-list(a)python.org>, Michael Torrie <torriem(a)gmail.com> wrote: >On 06/28/2010 02:31 PM, Aahz wrote: >> In article <mailman.2300.1277754755.32709.python-list(a)python.org>, >> Michael Torrie <torriem(a)gmail.com> wrote: >>> >>> True. But you can't really criticize a language's implementation of OOP >>> without a good understanding of the "pure" OO language. For example, in >>> Smalltalk If/Then statements are actually methods of Boolean objects. >>> >From a certain point of view that's extremely appealing (consistent, >>> anyway). Almost functional in nature. They are not implemented this >>> way in Python, so that's one thing you could argue is not OO about Python. >> >> Python is in no way a pure OOP language. (I assume you're aware of this, >> but your phrasing leaves that in doubt.) > >My phrasing leaves that in doubt? How does my example of how Smalltalk >implements if/then vs how Pyton's implementation leave that in doubt? >The last sentence alone is very clear. Actually, it's precisely the last sentence that creates doubt: by saying "one thing", it's easy for a careless reader to infer that otherwise you would think that Python is a pure OOP. <shrug> Not a big deal, just thought it deserved clarification. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra
From: Stephen Hansen on 1 Jul 2010 10:53 On 7/1/10 7:31 AM, WANG Cong wrote: > On 06/30/10 01:20, Stephen Hansen<me+list/python(a)ixokai.io> 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. :) The two are diametrically opposed in fact, quite often. Sometimes that's not the case, but that is the exception and not the rule. >> 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? Syntax is always a burden, by definition. Everything added to the language is a burden. Each has a cost. Some, that cost is light, and the benefits great-- but in others > It is easy to understand. For you. It makes it harder for someone to learn the language. _Every_ bit of syntax does. Its one more thing that you have to learn before you read down a piece of code and easily grok exactly what its doing. >> 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. For you. You find setattr() more understandable. Others do not. You make a distinction between "programming classes" and what you previously called "metaprogramming", others do not. The importance of "programming classes" is something that exists in your mind only -- well, yours and anyone who chooses to think so as well, which is certainly quite a few people. But I'll thank you to not impose your sense of importance of these things on me. There is nothing at all notable about the difference of "programming classes" verses "programming non-classes" to me. :) You're free to make the distinction in your own code; not everyone defines "programming classes" as anything special. As for setattr... sorry, but your assertion is simply untrue: there is nothing about it which says you are adding a new attribute. You can use it to set any attribute you want, even one that already exists and was defined previously. 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". The existence of one does *nothing at all* to invalidate the utiltiy of the other. You use one construct in the usual-case of setting the value of an attribute which is known at coding-time (irregardless of if that attribute existed before: /neither/ of these constructs make /any/ distinction between adding a new attribute and replacing an old one that already existed), and one when the name of that attribute is dependent on some runtime state. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Aahz on 1 Jul 2010 10:55
In article <m31vbnntwn.fsf(a)gmail.com>, WANG Cong <xiyou.wangcong(a)gmail.com> wrote: >On 07/01/10 13:49, Stephen Hansen <me+list/python(a)ixokai.io> wrote: >>Wang Cong deleted the attribution for Aahz: >>> >>> 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? Not in the slightest. However, elegance is often achieved by aiming for perfection. >IMHO, if a language is perfect, it is elegant. Probably, but the converse is completely not true. P->Q does not imply Q->P, and if this isn't obvious to you, you need to study formal logic (which would be of assistance to you in your other programming endeavors). -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra |