Python dynamic attribute creation
in [Python]
|
From: Gregory Ewing on 2 Jul 2010 04:41 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
From: Gregory Ewing on 2 Jul 2010 04:54 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
From: Gregory Ewing on 2 Jul 2010 05:07 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
From: Gregory Ewing on 2 Jul 2010 05:42 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
From: Bruno Desthuilliers on 2 Jul 2010 05:59
WANG Cong a �crit : > On 07/01/10 23:19, Stephen Hansen <me+list/python(a)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 "meta"whatever 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. |