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

[Anthony Baxter]

[meta-comment: my congratulations to Ben North for managing this 
process as painlessly as any syntax discussion I've ever seen. 
Regardless of the outcome, I'd like to see this thread referenced 
in the appropriate places as a great example of how to propose new 
features in Python]

I've been thinking about this on and off some more, and the only use 
case I can see that's even vaguely useful (imho) is method lookup. 
Most other cases I can think of are really better handled with 
dictionaries rather than objects. I'm not sure that this is really 
worth adding syntax for. 

> I think the "obj.[attr_name]" syntax has the most support.  

If there is to be new syntax, I prefer this over any of the other 
options. 

> and the "wrapper class" idea of Nick Coghlan:
>    attrview(obj)[foo]

This also appeals - partly because it's not magic syntax <wink>

> 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))

I guess that's a matter of preference - given how rarely I see 
constructs like this, I don't have a problem with the latter. (But 
see above comment about method lookup) I really cannot think of a 
single time where the setattr() form of this syntax is something I 
would have used. Anecdotally, I asked a couple of other folks for 
their opinions, and they were also fairly unimpressed with it (but 
of course the plural of anecdote is not "data" :-) so take that for 
what it's worth). 

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

I haven't touched Matlab for many years - but why wouldn't using 
dictionaries be preferable here? You have much less restrictions on 
key names (vs attribute names), for instance. 

> 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

I'd disagree. Those 1% losses add up, and it takes a heck of a lot 
of work to claw them back. Again, this is through my filter 
of "marginal value".



-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.