Python dynamic attribute creation
in [Python]
|
From: WANG Cong on 1 Jul 2010 11:46 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, 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.
From: Stephen Hansen on 1 Jul 2010 12:51 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/
From: Rami Chowdhury on 1 Jul 2010 14:11 On 2010-07-01 23:42, WANG Cong wrote: > On 07/01/10 22:53, Stephen Hansen <me+list/python(a)ixokai.io> wrote: > > > > > One uses assignment syntax when the name of the attribute they are > > setting is known at the time when one writes the code. > > > > One uses the setattr function when the name of the attribute is not > > known until runtime. > > > > The difference has *nothing at all* to do with "programming classes" > > or "dynamic" vs "static". > > > > This is exactly what I am thinking. > > What we differ is that if using both assignment syntax and setattr() > builtin function is a good design. You think the current design which > lets them co-exist is more understandable, while I think this is less > perfect and then not that more understandable. :) 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
From: Steven D'Aprano on 1 Jul 2010 21:10 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
From: Chris Rebert on 1 Jul 2010 22:02
On Thu, Jul 1, 2010 at 6:10 PM, Steven D'Aprano <steve(a)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 |