[Python-Dev] Summary of "dynamic attribute access" discussion
ben at redfrontdoor.org
Tue Feb 13 14:50:01 CET 2007
The support for the including the feature at all is still not unanimous.
Perhaps the way forward is to try to reach consensus on the favourite
(or least-unfavourite) syntax, and I'll revise the PEP and sample
I think the "obj.[attr_name]" syntax has the most support. To stop this
going round in circles for ages, then, I will take this as the winner.
I'll mention the other contenders in the PEP, including the new
"visually distinctive" suggestions
and the "wrapper class" idea of Nick Coghlan:
(I personally think the "attrview" idea results in slightly
cluttered-looking code, and prefer the visual simplicity of
One of the new opinions against the feature at all was Steve Holden's:
> This seems to me to take Python further away from the "Computer
> Programming for Everyone" arena and closer to the "Systems Programming
> for Clever Individuals" camp.
I don't agree. People who find it clearer to write
x = getattr(obj, attr_name)
can continue to do so. Now, of course, a person with such a preference
has no control over what other people write, so everybody will have to
understand what the new syntax means, but I think it's quite mnemonic.
It's a combination of the "." attribute look-up and the "" dictionary
Steve, further down his message, continues:
> It threatens to reduce Python's readability substantially
obj.[attr_name] = other_obj.[attr_name]
a much clearer expression of the "assignment" intent of this statement
setattr(obj, attr_name, getattr(other_obj, attr_name))
in the same way that I find
my_dict[new_key] = new_value
clearer than a hypothetical
setvalue(my_dict, new_key, new_value)
Opinion is divided on whether it's a readability win, but I think it
*is* a win. (Well, I would, I suppose). My experience in Matlab was
that code became much more readable when they introduced "dynamic
fields", especially in code which sets "fields" in one variable from
"fields" in others. I don't know whether others on this list have
worked in Matlab and have any opinions from their experience.
Turning now to the performance question, Steve also writes:
> > Is 1% "too much" for this feature?
> Yes. I believe it would decrease the sum total of Python's efficiency
> for a very marginal return in performance on a very marginal feature.
The performance question is important, certainly. Initial reaction on
python-ideas was that a 1% cost would not count as substantial, but of
course quicker would be better, and there were a couple of suggestions
as to how the implementation could be improved. I agree that
"readability is more important than efficiency", and I think a 1%
efficiency loss would be "small" compared to what I think is a
readability win, especially in cases like the example above.
Thanks very much for all the interest in this idea. I think I've got
enough of a sense of the list's reaction to update the PEP, and will do
so over the next couple of days. I'll then re-post it so that everyone
can check I haven't misrepresented their opinion, and take it from
More information about the Python-Dev