On 9 Feb 2008, at 20:22, Raymond Hettinger wrote:
Perhaps, the dict() constructor should accept any object with a __dict__ method.
The principle is that almost any object that has key and value pairs (named tuples for example) should be readily convertable to and from a dictionary. The current, non-uniform alternative is for the object to provide an asdict() method and for the user to call it directly.
I think the upcoming Abstract Base Classes support will take care of this... a dict-like class can register with the Mapping base class (or whatever it is to be called), and that could signal the dict() constructor to check for items() and use that if it's available. Your way would confuse things somewhat, because that's not really what __dict__ signifies. Suppose you subclass `dict` and give it some attributes. Their values will be stored in the instance's __dict__, while any keys set on the instance (i.e. __setitem__ not __setattr__) will not. In general, I think it's best to keep attributes and mapping contents cleanly separated; I don't think it would be good if dict() implicitly became a somewhat unpredictable near-clone of vars().