I've sent an updated version of PEP 363 to the editors, which includes the following summary of the discussion. I hope I've captured the important points, but please let me know if there's something important I've left out or misrepresented. - - - - 8< - - - - Mailing Lists Discussion Initial posting of this PEP in draft form was to python-ideas on 20070209 [2], and the response was generally positive. The PEP was then posted to python-dev on 20070212 [3], and an interesting discussion ensued. A brief summary: Initially, there was reasonable (but not unanimous) support for the idea, although the precise choice of syntax had a more mixed reception. Several people thought the "." would be too easily overlooked, with the result that the syntax could be confused with a method/function call. A few alternative syntaxes were suggested: obj.(foo) obj.[foo] obj.{foo} obj{foo} obj.*foo obj->foo obj<-foo obj@foo obj.[[foo]] with "obj.[foo]" emerging as the preferred one. In this initial discussion, the two-argument form was universally disliked, so it was to be taken out of the PEP. Discussion then took a step back to whether this particular feature provided enough benefit to justify new syntax. As well as requiring coders to become familiar with the new syntax, there would also be the problem of backward compatibility --- code using the new syntax would not run on older pythons. Instead of new syntax, a new "wrapper class" was proposed, with the following specification / conceptual implementation suggested by Martin Loewis: class attrs: def __init__(self, obj): self.obj = obj def __getitem__(self, name): return getattr(self.obj, name) def __setitem__(self, name, value): return setattr(self.obj, name, value) def __delitem__(self, name): return delattr(self, name) def __contains__(self, name): return hasattr(self, name) This was considered a cleaner and more elegant solution to the original problem. The decision was made that the present PEP did not meet the burden of proof for the introduction of new syntax, a view which had been put forward by some from the beginning of the discussion. The wrapper class idea was left open as a possibility for a future PEP.