On 2/13/07, "Martin v. Löwis" <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
