From: Gregory Ewing on
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.

From: Gregory Ewing on
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


you would have to write something like


just to allow for the possibility of writing


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.

From: Gregory Ewing on
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.

From: Gregory Ewing on
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

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

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!

From: Bruno Desthuilliers on
WANG Cong a �crit :
> On 07/01/10 23:19, Stephen Hansen <me+list/python(a)> 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.