> On 2/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > [snip] > > I've tried this out on Brett's urllib & urllib2 examples below. (calling > > the new builtin attrview() to emphasise the fact that it retains a > > reference to the original instance). I don't consider it any uglier than > > the proposed syntax changes, and it provides a few other benefits: > > > > - the two-argument form is naturally available as the .get() method > > on the resulting dict-like object (e.g. "attrview(obj).get(some_attr, > > None)") > > > > - hasattr() is naturally replaced by containment testing (e.g. > > "some_attr in attrview(obj)") > > > > - keywords/builtins are easier to look up in the documentation than > > symbolic syntax > > > > With this approach, performance would be attained by arranging to create > > the view objects once, and then performing multiple dynamic attribute > > accesses using those view objects.
On 2/13/07, Collin Winter <[EMAIL PROTECTED]> wrote: > This changes my vote: +1 on including attrview(), -1 on the syntax proposal. Me too! I imagine that the addition of the proposed "obj.[name]" syntax to Python 2.6 would lead to more software that will not run on 2.5 and earlier versions. I don't think the benefits outweigh this backward incompatibility of new code. Therefore I'm -1 on including "obj.[name]" in Python 2.6. For Python 3000, I think it would be alright. With "attrview(obj)[name]" it would be possible to provide a fallback implementation in the same module for pre-2.6 users, so +1 for that. Johann C. Rocholl _______________________________________________ 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
