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

[Greg Falcon]

On 2/13/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Anthony Baxter schrieb:
> >> and the "wrapper class" idea of Nick Coghlan:
> >>    attrview(obj)[foo]
> >
> > This also appeals - partly because it's not magic syntax <wink>
>
> It's so easy people can include in their code for backwards
> compatibility; in Python 2.6, it could be a highly-efficient
> builtin (you still pay for the lookup of the name 'attrs',
> of course).

attrview() (or whatever name it ultimately gets) feels Pythonic to me.
 It's a lot cleaner than getattr/setattr/hasattr/delattr.  It's
perhaps not entirely as pretty as .[], but it's close enough that I
question whether adding new syntax is worth it.

The easy backwards compatibility is the huge feature here, but there
are a couple of others.

Because attrview() can be made to support much of the dict interface,
it can clearly express things the .[] syntax cannot, like:
* attrview(obj).get(key, default)
* attrview(obj).setdefault(key, []).append(x)

Also, because attrview objects implement a mapping, they can be used
in interesting ways in places that expect a mapping.  (The locals
parameter to eval() comes to mind, but I'm sure there would be many
other good uses we won't be able to predict here.)

Guido van Rossum wrote:
> 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.

Of course there is an aliasing here, but it's being explicitly
constructed, and so I fail to see what is problematic about it.  You
propose in PEP 3106 that Py3k's items/keys/values dictionary methods
should return wrapper objects, which provide a different interface to
the same data, and which can be used to mutate the underlying objects.
 Aren't the set of ailasing concerns in these two cases exactly the
same?

+1 for attrview(), +0 for .[] syntax. (-1 for .[] if attrview() is accepted.)

Greg F