Python dynamic attribute creation

[Stephen Hansen]

On 7/1/10 7:31 AM, WANG Cong wrote:
> On 06/30/10 01:20, Stephen Hansen<me+list/python at 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/