[Python-Dev] Summary of "dynamic attribute access" discussion

[Ben North]

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
implementation.

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

   obj@[foo]
   obj.[[foo]]

and the "wrapper class" idea of Nick Coghlan:

   attrview(obj)[foo]

(I personally think the "attrview" idea results in slightly
cluttered-looking code, and prefer the visual simplicity of
"obj.[foo]".)


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
look-up.

Steve, further down his message, continues:
> It threatens to reduce Python's readability substantially

I find

   obj.[attr_name] = other_obj.[attr_name]

a much clearer expression of the "assignment" intent of this statement
than

   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)

would be.

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
there.

Ben.