Python dynamic attribute creation

[Stephen Hansen]

On Fri, Jun 25, 2010 at 11:03 AM, WANG Cong <xiyou.wangcong at gmail.com>wrote:

> On 06/25/10 17:25, Steven D'Aprano <steve at 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.typooooo = "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(xxxx)' 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.wangcong at gmail.com>
 wrote:

> On 06/25/10 15:34, Bruno Desthuilliers
> <bruno.42.desthuilliers at 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 you're saying here either.


-- Ix
  m e (AT) i x o k a i (DOT) i o



On Fri, Jun 25, 2010 at 11:23 AM, WANG Cong <xiyou.wangcong at gmail.com>
 wrote:

> On 06/25/10 14:31, Richard Thomas <chardster at gmail.com> wrote:
> > 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.


In general, Python does not enforce restrictions upon the programmer. That's
simply the way it is. If you don't like it, if you think it should protect
you from yourself -- this is not the language for you, that's all.

Python allows you to do basically whatever you want, with certain exceptions
-- it won't generally guess what you mean, and will almost never do any sort
of implicit conversion, and hell, 'implicit' is just a dirty word in general
so its not likely to do much automagically.

>From a "language design issue", the dynamism IS one of the key fundamental
design decisions of the language. Its not accidental. Sure, there's
tradeoffs for that. Its got strengths, and weaknesses. Pros and cons. But
that's the language. A "less-Dynamic" Python is possible, but it wouldn't be
Python anymore, and a LOT of very successful things people do with Python
would stop working.

Or just be a lot uglier. Pretty is actually a fundamental design decision
too :)

Generally speaking. Exceptions always exist.

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20100625/cf19bfb6/attachment-0001.html>