I consider __dict__ an implementation detail

March 11, 2007

Almost all Python objects implement their namespace as a Python dictionary, which they expose as their __dict__ member. You can do interesting things by playing around with this dictionary directly, for example adding bulk name/value mappings to an object by just doing something like obj.__dict__.update(pairs).

I don't like doing this, because I consider __dict__ to be an implementation detail, or at least fairly magical, and thus I feel that I shouldn't be playing around with it; I prefer to get the same results with more general higher-level things like setattr. Seeing code that uses __dict__ makes me vaguely twitchy.

In some sense __dict__ isn't merely an implementation detail, because it is sufficiently well documented (and necessary for things like __setattr__) that it will be sticking around. In another sense it is, because not all objects have a __dict__ (and even when they have one, not all of their attributes necessarily show up there), so you can't assume that you can use it to fish around in an arbitrary object. If you do anyways, you're making assumptions about how other code implements its objects that may come to bite you someday.

(The most obvious case of objects without a __dict__ is instances of classes that use __slots__.)

I'm aware that this is just a personal twitch, and possibly a silly one at that. A lot of Python programmers are perfectly happy to use __dict__, and I've committed worse hacks in my own code without thinking too hard.

Written on 11 March 2007.
« Weekly spam summary on March 10th, 2007
New warning messages might as well be fatal errors »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 11 20:46:50 2007
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.