
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:
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 <python@rcn.com> wrote:
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)?
-- --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 <python@rcn.com> wrote:
-- ===== --Ryan E. Freckleton

Raymond Hettinger wrote:
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 <rnd@onego.ru> wrote:
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/)

On 9 Feb 2008, at 20:22, Raymond Hettinger wrote:
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 <python@rcn.com> wrote:
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)?
-- --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 <python@rcn.com> wrote:
-- ===== --Ryan E. Freckleton

Raymond Hettinger wrote:
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 <rnd@onego.ru> wrote:
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