On 7/1/10 7:31 AM, WANG Cong wrote:
On 06/30/10 01:20, Stephen Hansen<me+list/pyt...@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/
--
http://mail.python.org/mailman/listinfo/python-list
