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. Raymond
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().
On Feb 9, 2008 5:22 PM, Raymond Hettinger
Perhaps, the dict() constructor should accept any object with a __dict__ method.
Won't that interfere with the existing __dict__ *attribute* of most objects (e.g. modules)?
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.
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
I'd rather have the dict built-in function be a dynamically
over-loadable (generic) function. I think it's a better fit than
adding another __special__ method. The same technique could be used
for the other built-in types and user created classes.
Somewhat similar to Eiffel, actually...
On Feb 9, 2008 6:22 PM, Raymond Hettinger
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.
Raymond _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- ===== --Ryan E. Freckleton
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.
Raymond
BTW, will the coming ABC have classes with "setattr ~= setitem" functionality? Yes, its quite easy to do (docstring from web.py utils.Storage is not longer than implementation): """ A Storage object is like a dictionary except `obj.foo` can be used in addition to `obj['foo']`. >>> o = storage(a=1) >>> o.a 1 >>> o['a'] 1 >>> o.a = 2 >>> o['a'] 2 >>> del o.a >>> o.a Traceback (most recent call last): ... AttributeError: 'a' """ At least, this could set the bare protocol of such hybrid for anyone to subclass. -Roman
On Feb 10, 2008 10:31 AM, Roman Susi
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.
Raymond
BTW, will the coming ABC have classes with "setattr ~= setitem" functionality?
No-- this will just cause confusion about which API to use. Go use JavaScript if you want that. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Adam Atlas -
Guido van Rossum -
Raymond Hettinger -
Roman Susi -
Ryan Freckleton