Python dynamic attribute creation
in [Python]
|
From: WANG Cong on 1 Jul 2010 11:02 On 06/27/10 09:06, Steven D'Aprano <steve(a)REMOVE-THIS-cybersource.com.au> 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.
From: Stephen Hansen on 1 Jul 2010 11:01 On 7/1/10 7:44 AM, WANG Cong wrote: > On 07/01/10 13:49, Stephen Hansen<me+list/python(a)ixokai.io> 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. > > > Isn't elegance somewhat equalent to perfection? > IMHO, if a language is perfect, it is elegant. No. > However, in the other sub-thread, you seem to be against being perfect > for Python. :) Yes. Perfection, if it exists (it does not), would probably have the property of elegance. Unless by 'perfect' we mean, 'perfectly models this certain paradigm of thought', in which case 'perfect' is really very limited when someone wants to go do something with a different paradigm all together. Technical elegance (as opposed to like, the elegance of silk) is the clear execution of a thought or process in a concise, simple way. It's utterly impossible for any language to be perfect; no language can possibly express all thought and processes of thought in an ideal form. Every language will have things it is better at expressing then others-- thoughts and ways of thinking that flow better from it then others. A language can be elegant though (I don't even think Python is: it just tries to be): but not everything you do with it will then be elegant itself. Elegance happens in the specific: a certain solution, a key design of a system, there you find elegance. It doesn't exist in the general. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: WANG Cong on 1 Jul 2010 11:15 On 06/28/10 17:43, Bruno Desthuilliers <bruno.42.desthuilliers(a)websiteburo.invalid> wrote: > Carl Banks a écrit : >> On Jun 27, 3:49 am, Bruno Desthuilliers >> <bdesth.quelquech...(a)free.quelquepart.fr> wrote: >>> WANG Cong a écrit : >>> >>>> On 06/26/10 00:11, Neil Hodgson <nyamatongwe+thun...(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. >>> 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.
From: Stephen Hansen on 1 Jul 2010 11:19 On 7/1/10 8:02 AM, WANG Cong wrote: > On 06/27/10 09:06, Steven D'Aprano<steve(a)REMOVE-THIS-cybersource.com.au> 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. :) setattr is perfectly ordinary. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: WANG Cong on 1 Jul 2010 11:42
On 07/01/10 22:53, Stephen Hansen <me+list/python(a)ixokai.io> 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. |