Inheriting from dict (was: Python dynamic attribute creation)
On 7/2/2010 1:54 AM, Gregory Ewing wrote: WANG Cong wrote: Yeah, my point is why setattr() for dynamic attributes while assignments for static attributes? If you mean using exactly the same syntax for both, that would require making the static case more verbose, e.g. instead of foo.blarg you would have to write something like foo.(blarg) just to allow for the possibility of writing foo.(some_arbitrary_expression) Instead of dynamically adding attributes, there's another option: deriving a class from dict: class HTMLtag(dict) : def __init__(self, tagtype) : self.tagtype = tagtype def __str__(self) : # generate source HTML tag return( + self.tagtype + + .join(map(lambda item: '%s=%s' % item, self.items())) + tag1 = HTMLtag(a) tag1['href'] = http://www.example.com; tag1['class'] = adurl s = str(tag1) # converts to string This has some advantages. The elements of the dictionary aren't in the same namespace as the attributes of object, so there's no problem with name clashes. Nor is there a problem with reserved words. BeautifulSoup stores HTML tag attributes as object attributes, and they have to special case things like class. You can iterate over all the elements of the dictionary (as the __str__ function does above) without interference from attributes which aren't data items. There's no problem with values that aren't valid attribute strings. (Python 2.x won't accept Unicode attributes, for example.) There's no risk of security injection problems because external data overrode a member name or some crucial data attribute. If you find yourself having to write code to avoid any of those problems, like prefixing dynamic attribute names with some symbol to avoid name clashes (or realize, after reading this, that your code has a vulnerability because it's not doing that), it may be better to inherit from dict rather than setting attributes explicitly. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: If you think setattr() is as ordinary as a trivial assignment, I will argue with you, this is personal taste. To my way of thinking, getattr() and setattr() are the fundamental way of accessing attributes in Python. The dot notation is just syntactic sugar for the overwhelmingly common case of a static attribute name. So the dot-notation is more ordinary in the sense of being more commonly used, but not in the sense of being a simpler operation. Both are doing exactly the same thing underneath. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: Yeah, my point is why setattr() for dynamic attributes while assignments for static attributes? I think there may be a misunderstanding here. You seem to be thinking of dynamic attribute vs. static attribute as the distinction between creating a new attribute and modifying an existing one. But that's not what it means in this context -- dynamic just means that the attribute name is being computed rather than written into the program. In either case, the attribute may or may not be pre-existing. Why not unify them? If you mean using exactly the same syntax for both, that would require making the static case more verbose, e.g. instead of foo.blarg you would have to write something like foo.(blarg) just to allow for the possibility of writing foo.(some_arbitrary_expression) If you keep the existing static-attribute syntax, then you haven't really unified anything, you've just added a new syntax for dynamic attributes. And because dynamic attribute access is extremely rare, it's not considered worth having a special syntax for it. It's been suggested before, and rejected on those grounds. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: When I talked about OOP, it is general OOP, not related with any concrete programming languages. There isn't really any such thing, though. There is no universally agreed set of features that a language must have in order to be considered OOP. Arguments of the form Language L isn't really OOP because it doesn't have feature F don't wash with anyone who has studied a sufficiently wide variety of languages. Every OOP language has its own take on what it means to be OOP, and none of them is any more correct about it than another. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: 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. But, in Python, creating instance variables is *not* class-programming. It doesn't touch the class at all. In many OO languages, such as Simula, C++ and Java, one of the responsibilities of a class is to define what attributes its instances have. However, that really comes about because those languages are statically typed -- it's not an essential principle of OO at all. In Python, restricting what attributes an object can have is *not* considered to be a responsibility of the class. The class is just a convenient place to put stuff (mostly methods) that some bunch of objects all need to have. Anything beyond that is up to the objects themselves. It so happens that, in most Python programs, all the instances of a given class will usually have a well- defined set of attributes. But Python doesn't go out of its way to enforce that. This is just a part of Python's general philosophy of not requiring declarations. There are very few declarative constructs in Python -- even class and function definitions are executable statements that construct data structures at run time. The only true declarations are the 'global' and 'nonlocal' statements, and they only exist because without them there would be no way to achieve certain things. They are not there to enforce any kind of static check. Why does Python not require declarations? Because it makes code easier and faster to develop. Instead of having to spend time and effort writing declarations, you just get straight on and write the code that does the actual work. And if you change your mind and need to move things around, you don't have to perform extra work to keep the declarations up to date. This can be a big help in the early stages of development, when you're feeling your way and the design is fluid. It also makes the program easier to extend and modify later. The downside is that certain kinds of error, that would be caught at compile time in a more static language, don't show up until you run the program. But if you're testing properly -- which you need to do anyway, whatever language you're using -- they usually show up pretty soon, and aren't much harder to fix when they do. Experience has shown that the overall process -- design, programming, testing and debugging -- tends to be faster using a dynamic, fluid language such as Python, than a static one such as C++ or Java. And, many people would say, more fun as well -- which is a good enough reason on its own for using Python! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 07/01/10 23:19, Stephen Hansen me+list/pyt...@ixokai.io 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, setattr IS a trivial assignment. 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. No magic and no metawhatever involved. setattr is as simple as: def setattr(obj, name, value): obj.__setattribute__(name, value) which is *exactly* what gets called when you use the binding statement form ie obj.someattr = value which FWIW is just syntactic sugar for the former (just like the 'class' statement is just syntactic sugar for a call to type, etc). I fail to understand why you insist on seeing something as trivial as magic, metaprogramming or whatever. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 06/30/10 01:25, Ethan Furman et...@stoneleaf.us 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? What is a dynamic and what is a static attribute 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. Please start with learning Python's execution model (what exactly happens at runtime, what most statement are syntactic sugar for etc) and Python's object model (how are Python objects, classes, methods etc implemented, attributes lookup rules, metaclasses, descriptors etc). Then PERHAPS you MIGHT have a chance to help making Python more perfect. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Stephen Hansen a écrit : On 6/30/10 10:37 PM, Aahz wrote: In article4c29ad38$0$26210$426a7...@news.free.fr, Bruno Desthuilliersbruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article4c285e7c$0$17371$426a7...@news.free.fr, Bruno Desthuilliersbruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliersbdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) ...and this implies that Python has no focus on elegance because...? Nope, that was an answer about where the emphasis was in my previous statement. I don't mean Python don't care about or is devoid of elegance, just that it's not the primary concern - hence the has no pretention at part. 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 please gentlemen, let's not fight on this. This no religion, there's no dogma here, and no heretic to burn. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/30/10 01:25, Ethan Furman et...@stoneleaf.us 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 me+list/pyt...@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. :) 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 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 07/01/10 13:49, Stephen Hansen me+list/pyt...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 7/1/10 7:31 AM, WANG Cong wrote: On 06/30/10 01:20, Stephen Hansenme+list/pyt...@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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article mailman.2311.1277759128.32709.python-l...@python.org, Michael Torrie torr...@gmail.com wrote: On 06/28/2010 02:31 PM, Aahz wrote: In article mailman.2300.1277754755.32709.python-l...@python.org, Michael Torrie torr...@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 (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article m31vbnntwn@gmail.com, WANG Cong xiyou.wangc...@gmail.com wrote: On 07/01/10 13:49, Stephen Hansen me+list/pyt...@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 (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/27/10 09:06, Steven D'Aprano st...@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 specialness 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 7/1/10 7:44 AM, WANG Cong wrote: On 07/01/10 13:49, Stephen Hansenme+list/pyt...@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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/28/10 17:43, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: Carl Banks a écrit : On Jun 27, 3:49 am, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: WANG Cong a écrit : On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 7/1/10 8:02 AM, WANG Cong wrote: On 06/27/10 09:06, Steven D'Apranost...@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 specialness 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/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 07/01/10 22:53, Stephen Hansen me+list/pyt...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 07/01/10 23:19, Stephen Hansen me+list/pyt...@ixokai.io 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
Re: Python dynamic attribute creation
On 7/1/10 8:46 AM, WANG Cong wrote: 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. I'm going to try this one more time -- you place a great deal of importance and special properties on Classes and what they mean to object oriented programming. That is perfectly fine. In some languages, there is indeed a great deal of importance to Classes. They define a sort of formal structure, a contract, and the rules by which the program runs. Object Oriented Programming is ingrained in them as not just a means, but an end -- it's the Right Way to do things, the tenants of the OOP paradigm are ingrained as the rules of interaction between things. In these languages, modifying a class at runtime might indeed be strange, interesting, magical. In Python, none of this holds true. Python's classes are *created* at runtime. The 'class body' is executable code which is run when your program starts, the result of which is your class. Now, let me ask you a (rhetorical) question: exactly when are the attributes 'created' on a class? You say that adding attributes to an object is special, magical. Consider this relatively simple class: class Person(object): def __init__(self, name, age=21): self.name = name self.age = age I can instantiate that easily, of course: me = Person(Stephen, 29) This is all the normal, basic way we deal with classes and attributes right? Right. Here's the important detail. When __init__ is called, the person object has no attributes(*). None at all. Unlike in other more real OOP languages where they have attributes which are just basically uninitialized, here it has none. In the __init__, its adding attributes to that object which already exists on the fly-- at runtime. Now, here I do something magic: me.hair_color = brown I've now added a new attribute to the existing instance, what you're calling something special called class programming. The problem: that's the *exact same syntax* which was used in __init__. There's no difference between what happened in __init__, where we normally consider that we're defining our attributes, and what may happen later when you decide to add an attribute 'ont he fly'. The second case is special *only* if you *imagine* it is-- and it is special then *only* in your own mind. It is special, adding an attribute to a previously defined class, if you decide for yourself, classes are things that are set in stone or pre-defined in some way. Classes aren't pre-defined, they're entirely created and defined on the fly. That a certain 'on the fly' may happen early (right after you create an instance) or another may happen at any point later-- Python doesn't and can't even tell the difference (not by itself without any jumping through hoops at least). It's all the same. There's nothing magical about it. Except to you, *personally*. In your head, only. Its fine to believe that and treat classes as special for you: but its your *choice* to do so. If you want magic, go learn about metaclasses, descriptors, and such. Othewrise, I give up. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 2010-07-01 23:42, WANG Cong wrote: On 07/01/10 22:53, Stephen Hansen me+list/pyt...@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. :) Is this not the practicality / purity discussion from another subthread? You think it's less perfect (by which I think you actually mean less pure - but please correct me if I'm wrong). But you admit that it's more under- standable (i.e. it's more practical). Practicality beats purity, so the less pure solution wins. 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 Rami Chowdhury It always takes longer than you expect, even when you take Hofstadter's Law into account. -- Hofstadter's Law +1-408-597-7068 / +44-7875-841-046 / +88-01819-245544 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Thu, 01 Jul 2010 23:46:55 +0800, WANG Cong wrote: 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. There's nothing magic about metaprogramming. If you're a programmer, you write programs. Some of those programs will be programs about text (programming), programs about numbers (programming), programs about databases (programming), programs about staff performance data (programming), and programs about programs (metaprogramming). But it's still just programming, and there's nothing magical about it. Languages that try to frighten you away from metaprogramming are doing you a disservice. That's like teaching an electrical engineer how to make all sorts of devices, but not how to make voltmeters or ammeters because they're meta-electronics. I'm pretty sure that IT is the only discipline that cares about this distinction between normal work and meta work. Engineers are quite happy to make the tools they need to make the tools they need to make the tools they need to make something. Carpenters would think you were crazy if you said that building a scaffold was meta-carpentry and therefore magic and something to be avoided. There's even a children's song about the sort of loops you can get into when you need a tool X to fix some item Y, but you need Y in order to fix the tool first: http://www.songsforteaching.com/folk/theresaholeinthebucket.htm It's only in IT that meta work is considered special, and that (I think) is because of the influence of academia. Don't get me wrong, I'm a big fan of academia, but I think sometimes they need a good dose of reality. Back before IT was a discipline, people used to write self-modifying code and programs to generate programs and other metaprogramming all the time, and nobody thought twice about it. Now admittedly, *some* metaprogramming techniques (like self-modifying code) make debugging much, much harder, and therefore should be avoided *for that reason*, but that's nothing to do with metaprogramming. If you write code with variables like: a1649264273528924 = a1649269279528924 + a1645976427328924 that's just programming but it's damn near impossible to efficiently debug too. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Thu, Jul 1, 2010 at 6:10 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: snip Engineers are quite happy to make the tools they need to make the tools they need to make the tools they need to make something. Carpenters would think you were crazy if you said that building a scaffold was meta-carpentry and therefore magic and something to be avoided. +1 QOTW Cheers, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/29/2010 06:46 PM, WANG Cong wrote: On 06/29/10 17:48, Andre Alexander Bell p...@andre-bell.de wrote: var a a - should raise an variable 'unset' exception 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. I actually very much prefer Python's implementation with direct assignment, just because it's short and comprehensible. Regards Andre -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article 4c29ad38$0$26210$426a7...@news.free.fr, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article 4c285e7c$0$17371$426a7...@news.free.fr, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article 4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) ...and this implies that Python has no focus on elegance because...? Nope, that was an answer about where the emphasis was in my previous statement. I don't mean Python don't care about or is devoid of elegance, just that it's not the primary concern - hence the has no pretention at part. It may not be the primary concern, but elegance certainly is *a* primary concern. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/30/10 10:37 PM, Aahz wrote: In article4c29ad38$0$26210$426a7...@news.free.fr, Bruno Desthuilliersbruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article4c285e7c$0$17371$426a7...@news.free.fr, Bruno Desthuilliersbruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliersbdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) ...and this implies that Python has no focus on elegance because...? Nope, that was an answer about where the emphasis was in my previous statement. I don't mean Python don't care about or is devoid of elegance, just that it's not the primary concern - hence the has no pretention at part. 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. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ P.S. Yes, my wording is intentionally silly-religious. Not meant to be taken as anything but tongue-in-cheek. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Aahz a écrit : In article 4c285e7c$0$17371$426a7...@news.free.fr, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article 4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) ...and this implies that Python has no focus on elegance because...? Nope, that was an answer about where the emphasis was in my previous statement. I don't mean Python don't care about or is devoid of elegance, just that it's not the primary concern - hence the has no pretention at part. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
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.typo = 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 --
Re: Python dynamic attribute creation
On 06/29/10 17:48, Andre Alexander Bell p...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/27/10 12:01, Carl Banks pavlovevide...@gmail.com wrote: On Jun 25, 8:24 pm, WANG Cong xiyou.wangc...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Tue, Jun 29, 2010 at 9:48 AM, WANG Cong xiyou.wangc...@gmail.com wrote: On 06/27/10 12:01, Carl Banks pavlovevide...@gmail.com wrote: On Jun 25, 8:24 pm, WANG Cong xiyou.wangc...@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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: On 06/27/10 12:01, Carl Banks pavlovevide...@gmail.com wrote: On Jun 25, 8:24 pm, WANG Cong xiyou.wangc...@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~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: On 06/29/10 17:48, Andre Alexander Bell p...@andre-bell.de wrote: 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. If Python were going to be the same as other languages, what would be the point of having Python? 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. I, for one, am very happy that Python allows it -- if I wanted to jump through hoops for simple things I'd use some other language. 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. 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. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/29/10 9:48 AM, WANG Cong wrote: On 06/27/10 12:01, Carl Bankspavlovevide...@gmail.com wrote: On Jun 25, 8:24 pm, WANG Congxiyou.wangc...@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. The question is fundamentally invalid, really. Why do we need this-- What does need have to do with it? We use the standard assignment and deletion semantics because there's no reason not to; the syntax is readable, understandable, straight-forward, and useful. Why not make it harder-- you've basically asked repeatedly. Why would we make it harder? There's no reason to. There's no reason to change to setattr by default, for although it would make Python dynamic, it would be harder to be dynamic. When given a choice between easier and harder the answer is simply, always, easier. It is not for us to defend *why* -- easier wins, period. If you think that harder would be better, it is for you to defend why it *needs* to be harder. Not vice versa. It is easier is, by itself, the end of the justification. There need be no other, unless there is some compelling reason why making a certain thing easier is *bad* -- this is a real consideration that is made on occasion, but the burden of proof is on you. Also, since it is easier, why not drop the harder one, setattr()? Why would we? There are some corner cases where setattr is easier then other options (such as thing.__dict__[key]). There is no exclusive-OR here. There's no reason to drop the harder one. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/29/10 9:46 AM, WANG Cong wrote: 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. Python does not do restrictions by default, period. If you wish to not add new attributes to objects, it is up to you to police yourself. This is Python. This is how Python rolls. 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. 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. There has to be some real use-case, some *real* code out in the *real* world which is doing something, and its hard-- and you have to do this hard thing often enough that you are burdened by it-- and only then is it reasonable to ask for syntax to be added to Python to make it easier. Alternatively, if there's something that's not even possible for you to to today, but you have a *real* problem you'd like to solve, a *real* need to do something new: then you can ask for something to be added to the language. Barring that, its not worth the cost of making the language bigger. PEP 363 didn't meet that burden: sure, there's times when you need to do that-- I've done it several times-- but the solutions that exist to solve that problem (setattr) are good-enough that it isn't really much of a burden to do. Moreover, during the discussion of PEP 363, someone proposed (Raymond Hettinger, I think) an excellent recipe which not only made the 'good enough' quite a bit easier, but which a lot of people thought was even cleaner then syntax. So, PEP363 went the way of the dodo. Is Python perhaps less perfect, pure, with that addition to the language denied? Who cares? Perfection is what the Borg* worship, I like understandable. :) -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ P.S. *Not calling anyone a borg! Seven of Nine said they worshipped perfection, remember? -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Jun 29, 9:48 am, WANG Cong xiyou.wangc...@gmail.com wrote: On 06/27/10 12:01, Carl Banks pavlovevide...@gmail.com wrote: On Jun 25, 8:24 pm, WANG Cong xiyou.wangc...@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. Because the guy who wrote Python (our BDFL, Guido van Rossum) knows and understands your objection, but disagrees with you nonetheless. I've already told you why, and that's just going to have to be your answer. There's really nothing more to it than that. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/27/10 10:10 PM, Carl Banks wrote: On Jun 27, 3:49 am, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: WANG Cong a écrit : On 06/26/10 00:11, Neil Hodgsonnyamatongwe+thun...@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. Same. I've been informed that I find Objective-C rather comfortable and strangely Pythonic because its object model is based in Smalltalk, and although Python's a step or two farther removed (what with not embedding smalltalkish directly into another language), is as well. I don't think one needs to know Smalltalk to know much about OO. One might need to know Smalltalk to understand the history and perhaps some rationale of OO, _maybe_, but at this point-- the pure theory of OOP is taught and discussed far and wide entirely outside of the context of Smalltalk. Smalltalk may have originated it and may be one of the purest forms of the concept, but... To say you can't really know much about OOP without knowing much about Smalltalk seems basically, well, wrong. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Sun, Jun 27, 2010 at 6:49 AM, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: WANG Cong a écrit : On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. Guess I don't know much about OO then, despite having written OO code for at least the last ten years... Geremy Condra -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article 4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; I think that Python is extremely elegant, and that elegance is one of the attractions of Python for many people. In fact, PyCon 2009 had elegance begets simplicity as its t-shirt slogan. -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article viavn.238$vd2...@news-server.bigpond.net.au, Neil Hodgson nyamatongwe+thun...@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. Low level OOPLs like C++ and Delphi did not implement this for efficiency reasons. That reminds me of this quote: ...some experts might say a C++ program is not object-oriented without inheritance and virtual functions. As one of the early Smalltalk implementors myself, I can say they are full of themselves. --zconcept -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Aahz a écrit : In article 4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Carl Banks a écrit : On Jun 27, 3:49 am, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: WANG Cong a écrit : On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. 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). Hope this will at least help those I may have offended understand my point, however stupidly I expressed it :( B. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Alexander Kapps a écrit : (snip) While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: class Foo(object): def __init__(self): self.somearg = 0 f = Foo() f.soemarg = 42 ---^ There, typo, but still working It's something like a custom __setattr__ that errors out when trying to assign to an attribute that doesn't exists, Chicken and egg problem, really : f.__dict__['somearg'] doesn't exists until self.somearg = 0 is executed. The problem is that Python's methods are only thin wrapper around functions (cf http://wiki.python.org/moin/FromFunctionToMethod) so there's no difference between self.somearg = 0 in Foo.__init__ and f.somearg = 42. IOW, there's no way to implement this proposal without completely changing Python's object model. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article 4c285e7c$0$17371$426a7...@news.free.fr, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article 4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) ...and this implies that Python has no focus on elegance because...? -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/28/10 8:27 AM, Aahz wrote: In article4c285e7c$0$17371$426a7...@news.free.fr, Bruno Desthuilliersbruno.42.desthuilli...@websiteburo.invalid wrote: Aahz a écrit : In article4c2747c1$0$4545$426a7...@news.free.fr, Bruno Desthuilliersbdesth.quelquech...@free.quelquepart.fr wrote: Python has no pretention at elegance. That's not true at all. More precisely, I would agree with you if the emphasis is on pretention but not if the emphasis is on elegance; Python Zen, #9 (or #8 if you're a TrueHacker !-)) ...and this implies that Python has no focus on elegance because...? Um, yeah, seriously :) #1-#7 seem to all be quite about not just elegance, but how to define it :) -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Bruno Desthuilliers wrote: Alexander Kapps a écrit : (snip) While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: class Foo(object): def __init__(self): self.somearg = 0 f = Foo() f.soemarg = 42 ---^ There, typo, but still working It's something like a custom __setattr__ that errors out when trying to assign to an attribute that doesn't exists, Chicken and egg problem, really : f.__dict__['somearg'] doesn't exists until self.somearg = 0 is executed. The problem is that Python's methods are only thin wrapper around functions (cf http://wiki.python.org/moin/FromFunctionToMethod) so there's no difference between self.somearg = 0 in Foo.__init__ and f.somearg = 42. IOW, there's no way to implement this proposal without completely changing Python's object model. I must be missing something. Can you please explain why the whole object model would need to change? This seems to work quite well: class TypoProtection(object): def __init__(self): self.foo = 42 self.bar = 24 def _setattr(self, name, value): if name in self.__dict__: self.__dict__[name] = value else: raise AttributeError, %s has no '%s' attribute \ % (self.__class__, name) self.__class__.__setattr__ = _setattr t = TypoProtection() t.foo = spam t.bar = ham t.parrot = dead Traceback (most recent call last): File typo.py, line 20, in module t.parrot = dead File typo.py, line 10, in _setattr raise AttributeError, %s has no '%s' attribute % (self.__class__, name AttributeError: class '__main__.TypoProtection' has no 'parrot' attribute So, IIUC, all what would need to be done is to add an implicit __setattr__ at the end of __init__ . (Just want to understand, still not advocating this proposal) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Alexander Kapps wrote: Bruno Desthuilliers wrote: Alexander Kapps a écrit : (snip) While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: class Foo(object): def __init__(self): self.somearg = 0 f = Foo() f.soemarg = 42 ---^ There, typo, but still working It's something like a custom __setattr__ that errors out when trying to assign to an attribute that doesn't exists, Chicken and egg problem, really : f.__dict__['somearg'] doesn't exists until self.somearg = 0 is executed. The problem is that Python's methods are only thin wrapper around functions (cf http://wiki.python.org/moin/FromFunctionToMethod) so there's no difference between self.somearg = 0 in Foo.__init__ and f.somearg = 42. IOW, there's no way to implement this proposal without completely changing Python's object model. I must be missing something. Can you please explain why the whole object model would need to change? UHHM! Forget it. This of course doesn't work with setattr too. My stupidness. :-( -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/28/10 12:09 PM, Alexander Kapps wrote: This seems to work quite well: class TypoProtection(object): def __init__(self): self.foo = 42 self.bar = 24 def _setattr(self, name, value): if name in self.__dict__: self.__dict__[name] = value else: raise AttributeError, %s has no '%s' attribute \ % (self.__class__, name) self.__class__.__setattr__ = _setattr This will only work the first time you make an instance: thereafter, __setattr__ will be on the class and future instances will refuse to allow the creation of foo and bar, as they won't already exist in the new instance's dictionary. That said, you can certainly make a class that only allows pre-approved attributes and prevents the creation of on the fly ones. Something like (untested): class TypoProtection(object): ALLOWED_ATTRIBUTES = [foo, bar] def __setattr__(self, key, value): if key not in TypoProtection.ALLOWED_ATTRIBUTES: raise AttribuetError(TypoProtection does not have %s attribute. % (key,)) return object.__setattr__(self, key, value) Now, I would very rarely *do* such a thing, but you *could* if you wanted to. (You achieve a similar effect by abusing __slots__) -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/2010 09:39 PM, WANG Cong wrote: Thanks, I have to admit that I know nothing about Smalltalk. If you know nothing about Smalltalk then you really aren't in a position to talk about what is and is not OOP. Smalltalk is one of the original OOP languages and purists define OOP as the model that Smalltalk implemented. In many ways Python is like Smalltalk. Certainly it's more like Smalltalk than Java or C++. Although Python has a few pieces of syntactic sugar that aren't truly OO, Python is much more OO than C++ or Java, for the reasons that others have already posted. Some of your doubts concerning Python and OOP stem directly from your exposure to Java and C++'s paradigms 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... I don't think C++ has any syntactic support for dynamic metaprogramming, but I did read an article in Doctor Dobb's Journal that talked about dynamic inheritance in C++. The Boost library provides some static metaprogramming facilities for C++. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/27/2010 11:58 PM, Stephen Hansen wrote: To say you can't really know much about OOP without knowing much about Smalltalk seems basically, well, wrong. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
In article mailman.2300.1277754755.32709.python-l...@python.org, Michael Torrie torr...@gmail.com wrote: On 06/27/2010 11:58 PM, Stephen Hansen wrote: To say you can't really know much about OOP without knowing much about Smalltalk seems basically, well, wrong. 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.) -- 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/28/2010 02:31 PM, Aahz wrote: In article mailman.2300.1277754755.32709.python-l...@python.org, Michael Torrie torr...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 28/06/2010 20:23, Alexander Kapps wrote: Alexander Kapps wrote: Bruno Desthuilliers wrote: Alexander Kapps a écrit : (snip) While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: class Foo(object): def __init__(self): self.somearg = 0 f = Foo() f.soemarg = 42 ---^ There, typo, but still working It's something like a custom __setattr__ that errors out when trying to assign to an attribute that doesn't exists, Chicken and egg problem, really : f.__dict__['somearg'] doesn't exists until self.somearg = 0 is executed. The problem is that Python's methods are only thin wrapper around functions (cf http://wiki.python.org/moin/FromFunctionToMethod) so there's no difference between self.somearg = 0 in Foo.__init__ and f.somearg = 42. IOW, there's no way to implement this proposal without completely changing Python's object model. I must be missing something. Can you please explain why the whole object model would need to change? UHHM! Forget it. This of course doesn't work with setattr too. My stupidness. :-( Don't worry too much, looks like your nation's football is much better than your settattr knowledge. I'm now setting up another charity to parallel the home in Dublin for blind Irish referees. [1] Kindest regards. Mark Lawrence [1] google for Max Boyce Irish Referees -- http://mail.python.org/mailman/listinfo/python-list
[OT] Football was: Python dynamic attribute creation
Mark Lawrence wrote: On 28/06/2010 20:23, Alexander Kapps wrote: UHHM! Forget it. This of course doesn't work with setattr too. My stupidness. :-( Don't worry too much, looks like your nation's football is much better than your settattr knowledge. I very much appreciate your attempt to make me feel better, but please realize that not every German (or UK citizen) is a football fan(atic). FWIW, I don't give a dime (very, very much less actually) who wins what there. And I surely know a lot more about setattr, than about the Abseits (aside, offside, or such) rule (even if my setattr knowledge is plain zero) Having that said, I wish you all luck for your team! :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] Football was: Python dynamic attribute creation
On 29/06/2010 00:21, Alexander Kapps wrote: Mark Lawrence wrote: On 28/06/2010 20:23, Alexander Kapps wrote: UHHM! Forget it. This of course doesn't work with setattr too. My stupidness. :-( Don't worry too much, looks like your nation's football is much better than your settattr knowledge. I very much appreciate your attempt to make me feel better, but please realize that not every German (or UK citizen) is a football fan(atic). FWIW, I don't give a dime (very, very much less actually) who wins what there. And I surely know a lot more about setattr, than about the Abseits (aside, offside, or such) rule (even if my setattr knowledge is plain zero) Having that said, I wish you all luck for your team! :-) Alexander, Thank you for your response, but would you please be so kind as to raise an issue on the bug tracker, as I can only vaguely remember the last time we (English) had a team. :) Our Celtic cousins have been worse, and that really *IS* saying something. Kindest regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 06/25/10 15:34, Bruno Desthuilliers bruno.42.desthuilli...@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... cf Ethan's answer on this. Using assignments to create an attribute hides metaprogramming while using delattr() exposes it. Once again : in Python, none of this is metaprogramming - just plain ordinary programming. So called metaprogramming is just an artefact of static languages where datastructures are created at compile time. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : (snip) The point is why making metaprogramming easy is wonderful? Because it makes life easier ?-) AND, even if it were wonderful, why only this one, i.e. creating attributes by assignments, not other things? Like : class Test(object): a = 1 del Test.a ?-) 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. cf above. 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, Not when a class is just another ordinary object. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 06/25/10 17:25, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: On Fri, 25 Jun 2010 14:15:12 +0100, WANG Cong wrote: (snip) 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. :) Python has no pretention at elegance. It's a _very_ practical language. It's designed to help you get the job done, period. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong a écrit : On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Jun 27, 3:49 am, Bruno Desthuilliers bdesth.quelquech...@free.quelquepart.fr wrote: WANG Cong a écrit : On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong: From what you are saying, Smalltalk picks a way similar to setattr() in Python? addInstVarName is a method on ClassDescription objects. 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. :) No, that was only part of the problems you enumerated. You want to easily distinguish adding instance variables (possibly also other things) since these are 'metaprogramming'. Now, once setattr is available it is possible to call setattr any place where a function can be called so you are not going to be able to determine whether any particular statement, including o.f=1 adds a new instance variable. You would have to change Python a lot more to be able to determine easily from inspection whether a given statement is 'metaprogramming'. The main problem I had was that you were saying that adding an instance variable is a special form of programming when its just an ordinary part of programming in most languages. 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. C++ is still extremely limited. Can you show a C++ example where a metaprogram modifies an existing class to add an instance variable? Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/26/2010 05:39 AM, WANG Cong wrote: On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. 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, Yes, it is. I'm not quite sure how far RTTI actually goes, but I know that performance is a key issue in the design of C++. If you have a look at the developments toward C++0x, you will see that many new features are being proposed - C++ is an expert's language, designed to give an expert the most powerful tool possible, with the restriction that no new feature may have a negative performance impact on an existing feature. Adding actual dynamism would have a massive impact on performance and is thus, for C++, not acceptable. since C++ is a static programming language I think if this limits C++ to implement its dynamic metaprogramming actually... Thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Ixokai wrote: In what possible way is: setattr(foo, 'new_attr', 'blah') getattr(foo, 'new_attr') delattr(foo, 'new_attr') Better then: foo.new_attr = 'blah' foo.new_attr del foo.new_attr I don't understand what your argument is or problem is with the regular syntax, if you want to allow the former (all of which is currently possible in Python if you prefer this style) but not the latter (all of which also works, it just uses normal syntax as everyone would expect). Do you think it should be somehow tricky or more difficult to dynamically modify an instance at runtime? For that to hold, you have to provide some pretty compelling reasoning why dynamically modifying an instance at runtime is Not Good. Only then is there a good reason to make it more difficult. (Since Python doesn't really restrict things, just makes certain rare things that are undesirable a little harder to do) --Stephen While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: class Foo(object): def __init__(self): self.somearg = 0 f = Foo() f.soemarg = 42 ---^ There, typo, but still working It's something like a custom __setattr__ that errors out when trying to assign to an attribute that doesn't exists, just as default behavior. Sure, unittest are the Right Way(tm) to handle this, but there is a learning curve for new programmers wrt unittest. And disallowing this, doesn't take away any dynamism since setattr and friends are still there. Anyway, since I do a lot interactive programming I don't want it. It would hinder me a lot. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 6/26/10 9:01 AM, Alexander Kapps wrote: While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: I get where you're coming from, but I don't see why attributes should get such special typo-protection when locals and any other names shouldn't. I see it as an extension of Special cases aren't special enough to break the rules. -- and here I think the OP and I disagree most strongly. This characterization of adding attributes to an object as something else, some special kind of activity called metaprogramming I think I reject outright, whereas I believe -- though I do not claim to speak for him/her -- the OP's position is that using 'syntax' to add attributes is actually a special case/activity. I consider it the standard, normal behavior. If this is how I create a local variable: x = 1 And to read that variable, I simply refer to it as x, and if to read a defined attribute from an object I do: a.x Then, to me, the way in which I would set a new variable on that object is clearly: a.x = 1 I don't see why Python should special case setting an attribute on an object to be so wildly different then setting a local variable (or global, or anything else) as to require a special function call. The activity of adding an attribute to an object is no more special, IMHO, then adding a variable to the local scope. Now, true: I fully acknowledge that if you're in an OOP-mindset and you're choosing to use a certain style of programming (and one I frequently indulge in), then you may /choose/ to treat certain objects as special, as being more firmly structured, as having a formal definition. 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 specialness of the activity is entirely in your head, and to Python, its an entirely normal event. Python lets you associate significance with normal events so you can get things done. But its just plodding along not really drinking whatever kool-aid you are, though its happy you like your flavor and is entirely content with letting you think its playing ball with you on that. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
Stephen Hansen wrote: On 6/26/10 9:01 AM, Alexander Kapps wrote: While I personally don't agree with this proposal (but I understand why some people might want it), I can see a reason. When disallowing direct attribute creation, those typos that seem to catch newcommers won't happen anymore. What I mean is this: I get where you're coming from, but I don't see why attributes should get such special typo-protection when locals and any other names shouldn't. Well, I would sympathize with an attempt to add some kind of typo protection. Not build into the language, but I dream about a command line switch that invokes a test like pylint/PyChecker. I wish any of those would enter the standard distribution. I see it as an extension of Special cases aren't special enough to break the rules. -- and here I think the OP and I disagree most strongly. This characterization of adding attributes to an object as something else, some special kind of activity called metaprogramming I think I reject outright, whereas I believe -- though I do not claim to speak for him/her -- the OP's position is that using 'syntax' to add attributes is actually a special case/activity. I consider it the standard, normal behavior. If this is how I create a local variable: x = 1 And to read that variable, I simply refer to it as x, and if to read a defined attribute from an object I do: a.x Then, to me, the way in which I would set a new variable on that object is clearly: a.x = 1 I don't see why Python should special case setting an attribute on an object to be so wildly different then setting a local variable (or global, or anything else) as to require a special function call. The activity of adding an attribute to an object is no more special, IMHO, then adding a variable to the local scope. I fully agree with everything so far. As I said, i don't support this proposal, just that I can see a reason why some people might want this. I do this type of dynamic attribute addition (both data and methods) all day in my interactive sessions, which are a large part of my Python activity. Now, true: I fully acknowledge that if you're in an OOP-mindset and you're choosing to use a certain style of programming (and one I frequently indulge in), then you may /choose/ to treat certain objects as special, as being more firmly structured, as having a formal definition. 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 specialness of the activity is entirely in your head, and to Python, its an entirely normal event. That was an interesting insight, thank you for this. While I actually know all this, I indeed still seem to sometimes treat objects as fixed-once-defined-and-created entities. I just grep'ed all my code repository and found that I almost never do any on-the-fly attribute addition (totally contrary to my interactive work) You may have just opened the door the my next level of Python OO understanding. Thank you! :-) Python lets you associate significance with normal events so you can get things done. But its just plodding along not really drinking whatever kool-aid you are, though its happy you like your flavor and is entirely content with letting you think its playing ball with you on that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Sat, 26 Jun 2010 10:10:39 -0700, Stephen Hansen wrote: This characterization of adding attributes to an object as something else, some special kind of activity called metaprogramming I think I reject outright, whereas I believe -- though I do not claim to speak for him/her -- the OP's position is that using 'syntax' to add attributes is actually a special case/activity. I consider it the standard, normal behavior. +1 [...] 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 specialness 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. In fairness, the reason the other languages do so is probably so that the compiler can make optimizations leading to faster code, which is why CPython is a fairly plodding implementation. But that's due to the conservativeness of CPython: Unladen Swallow is faster, and PyPI is faster still, and the PyPI people expect to eventually be competitive with C for speed. Python lets you associate significance with normal events so you can get things done. But its just plodding along not really drinking whatever kool-aid you are, though its happy you like your flavor and is entirely content with letting you think its playing ball with you on that. Nice :) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Sat, Jun 26, 2010 at 6:06 PM, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: snip CPython is a fairly plodding implementation. But that's due to the conservativeness of CPython: Unladen Swallow is faster, and PyPI is faster still, and the PyPI people expect to eventually be competitive with C for speed. PyPy (http://pypy.org/), *not* PyPI (http://pypi.python.org/pypi). You're confusing a package index with a self-hosting interpreter; darn typos, eh? Cheers, Chris -- http://blog.rebertia.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Sat, 26 Jun 2010 18:35:25 -0700, Chris Rebert wrote:
On Sat, Jun 26, 2010 at 6:06 PM, Steven D'Aprano
st...@remove-this-cybersource.com.au wrote: snip
CPython is a fairly plodding implementation. But that's due to the
conservativeness of CPython: Unladen Swallow is faster, and PyPI is
faster still, and the PyPI people expect to eventually be competitive
with C for speed.
PyPy (http://pypy.org/), *not* PyPI (http://pypi.python.org/pypi).
You're confusing a package index with a self-hosting interpreter; darn
typos, eh?
Damn news client, it should force me to write:
set_language_name('PyPy')
to catch these sorts of errors and reduce the need for me to proof-read
my posts!
*wink*
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Jun 25, 8:24 pm, WANG Cong xiyou.wangc...@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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
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 Jun 25, 2:15 pm, WANG Cong xiyou.wangc...@gmail.com 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. (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. 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. Richard. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
You are thinking like a C programmer Why do you want the language to tie your hands? I want a language to give me the tools I need and get out of the way. The more assumptions that are baked into a language the more opportunities it has to be wrong. Furthermore, object oriented design is a useful paradigm, but it is not the be-all and end-all of how computer programming is done. You should use it where it fits and ignore it where it doesn't. Focus more on doing things elegantly and less on conforming to the popular paradigm du jour. On Fri, Jun 25, 2010 at 9:15 AM, WANG Cong xiyou.wangc...@gmail.com 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. (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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
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. FWIW, what you call metaprogramming is just ordinary programming - at least in Python. All your fears and concerns about Python's dynamism are just a priori learned from the mainstream BD culture. From experience, these are non-issues - unless of course misused by some fool, but then there's no way to prevent stupids from doing stupid things. So, yes, Python rely quite a lot on programmer's common sense and discipline. Now the good news is that is JustWork(tm). -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
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. 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. 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? 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. 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. 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* 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. 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. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Fri, Jun 25, 2010 at 6:15 AM, WANG Cong xiyou.wangc...@gmail.com wrote: 4) Also, this will _somewhat_ violate the OOP princples, in OOP, this is and should be implemented by inherence. Others have answered the rest fine, I just wanted to add: Who says we have to follow OOP principles, huh? If you want to follow OOP principles: Python will do absolutely nothing to stop you! All power to you. You're also free to break the principles if you choose to: this is the key point. Python lets you choose to. If you firmly believe in the principles, you can embrace them fully by simply never choosing to violate them in any way. Some languages force you to adopt the OOP paradigm and build its principles directly into the language. Python does not. A python object is not, necessarily, the same thing as an abstract Object in the OOP world. But you can use it as such an object if you want and do everything OOP needs, though some things (such as encapsulation) are done by convention more then a strict enforcement by the language. Or you can use it and abuse it and do some really interesting and slightly crazy things as you experiment with other paradigms (even some lesser known ones), perhaps inventing a new paradigm all together. :) Most of my code is pretty OOPish. But I have more then a few places where I dig out my metaclass dark magic and transform objects into some distinctly unique tool. Python's content with letting me do that. Not that I'd show anyone or admit to my vices publicly, though. :) --S -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 17:25, Steven D'Aprano st...@remove-this-cybersource.com.au 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 bruno.42.desthuilli...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/25/10 14:31, Richard Thomas chards...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
WANG Cong wrote: On 06/25/10 15:34, Bruno Desthuilliers bruno.42.desthuilli...@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~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Fri, Jun 25, 2010 at 11:03 AM, WANG Cong xiyou.wangc...@gmail.comwrote: On 06/25/10 17:25, Steven D'Aprano st...@remove-this-cybersource.com.au wrote: 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. :-) What other things? That you define this as 'metaprogramming' is really strange to me. I have no idea what you're talking about when you decide to call adding an attribute to an object that. Classes and instances are not static. They are created at runtime: thus, they can be changed at runtime. Why would you expect anything else? They aren't concrete 'things' like in certain other languages. 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. del obj.a works just fine. 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. :) Its quite elegant in fact. 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? Why complicate the language when there's perfectly good ways to solve the problem elsewhere? Especially if those ways -also- have significant benefits of their own. 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. Why shouldn't it allow it? If you care about having a firm, set series of attributes that can not change, then you will never add an attribute on the fly. Therefore, you will never run into a situation where you're confused on what attributes are available. Therefore, this works perfectly well as-is. Using 'setattr()' could also prove Python is a dynamic programming, but Python doesn't choose this by default. I don't understand what you're saying here. On Fri, Jun 25, 2010 at 11:18 AM, WANG Cong xiyou.wangc...@gmail.com wrote: On 06/25/10 15:34, Bruno Desthuilliers bruno.42.desthuilli...@websiteburo.invalid wrote: 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... Huh? Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type help, copyright, credits or license for more information. delattr built-in function delattr del obj.x invokes obj.__delattr_(x) just like obj.x = 1 invokes obj.__setattr__(x, 1), and there are delattr() and setattr() convenience functions for both. There's also a getattr() function (which ultimately calls obj.__getattr__) for the 'reading' of said attribute. I'm not sure what you think is missing. The object protocol is fully documented (and customizable). Using assignments to create an attribute hides metaprogramming behide, while using delattr() exposes it. I don't understand what
Re: Python dynamic attribute creation
On Fri, Jun 25, 2010 at 12:51 PM, Stephen Hansen me+list/pyt...@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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 25/06/2010 19:23, WANG Cong wrote: On 06/25/10 14:31, Richard Thomaschards...@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. 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? Kindest regards. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
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. Low level OOPLs like C++ and Delphi did not implement this for efficiency reasons. Neil -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Jun 25, 6:15 am, WANG Cong xiyou.wangc...@gmail.com 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. 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. 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. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On Fri, 25 Jun 2010 19:31:24 -0700, Carl Banks wrote: 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. And sometimes a horrible warning *wink* -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/26/10 03:31, Carl Banks pavlovevide...@gmail.com wrote: On Jun 25, 6:15 am, WANG Cong xiyou.wangc...@gmail.com 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 Fri, Jun 25, 2010 at 8:24 PM, WANG Cong xiyou.wangc...@gmail.com wrote: 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. In what possible way is: setattr(foo, 'new_attr', 'blah') getattr(foo, 'new_attr') delattr(foo, 'new_attr') Better then: foo.new_attr = 'blah' foo.new_attr del foo.new_attr I don't understand what your argument is or problem is with the regular syntax, if you want to allow the former (all of which is currently possible in Python if you prefer this style) but not the latter (all of which also works, it just uses normal syntax as everyone would expect). Do you think it should be somehow tricky or more difficult to dynamically modify an instance at runtime? For that to hold, you have to provide some pretty compelling reasoning why dynamically modifying an instance at runtime is Not Good. Only then is there a good reason to make it more difficult. (Since Python doesn't really restrict things, just makes certain rare things that are undesirable a little harder to do) --Stephen -- http://mail.python.org/mailman/listinfo/python-list
Re: Python dynamic attribute creation
On 06/26/10 00:11, Neil Hodgson nyamatongwe+thun...@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. 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 et...@stoneleaf.us wrote: WANG Cong wrote: On 06/25/10 15:34, Bruno Desthuilliers bruno.42.desthuilli...@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... 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 breamore...@yahoo.co.uk wrote: On 25/06/2010 19:23, WANG Cong wrote: On 06/25/10 14:31, Richard Thomaschards...@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. 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 ian.g.ke...@gmail.com wrote: On Fri, Jun 25, 2010 at 12:51 PM, Stephen Hansen me+list/pyt...@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. 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
