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

[Guido van Rossum]

On 2/13/07, Anthony Baxter <anthony at interlink.com.au> wrote:
> [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]

Seconded.

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

Agreed again.

> > and the "wrapper class" idea of Nick Coghlan:
> >    attrview(obj)[foo]
>
> This also appeals - partly because it's not magic syntax <wink>

Not to me -- magic objects are harder to grok than magic syntax; the
magic syntax gives you a more direct hint that something unusual is
going on than a magic object. Also, Nick's examples show (conceptual)
aliasing problems: after "x = attrview(y)", both x and y refer to the
same object, but use a different notation to access it.

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

This is probably moot given the infrequency.

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

I missed discussion of the source of the 1%. Does it slow down pystone
or other benchmarks by 1%? That would be really odd, since I can't
imagine that the code path changes in any way for code that doesn't
use the feature. Is it that the ceval main loop slows down by having
two more cases? That's extremely noisy data; I've seen cases where
adding code would actually slow it up, due to the magic of cache
collisions. If that's all, I am taking the 1% figure with a lot of
salt.

There was some discussion of grammar and priorities. IMO the '.' and
'[' should remain separate tokens; the grammar for 'trailer' grows a
new alternative:

  trailer: ... | '.' NAME | '.' '[' test ']'

There are no ambiguities in this grammar. (Since it needs to evaluate
to a string I don't see the need to use testlist.)

Regarding hasattr(): yes, this won't have an alternative in syntax
yet. IMO that's fine; it means we'll be catching AttributeError
instead of using "look before you leap", which if fine with me. As for
the 3-arg version of getattr(), it's still there.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)