a clean way to define dictionary

Bengt Richter bokr at oz.net
Fri Jun 20 17:57:46 CEST 2003

On 20 Jun 2003 15:57:07 +0100, Alexander Schmolck <a.schmolck at gmx.net> wrote:

>mis6 at pitt.edu (Michele Simionato) writes:
>> Sorry for the typo, of course I meant __setitem__/__getitem__. 
>> I am saying that a workaround for the change of the constructor signature 
>> is to subclass dict and to override the constructor. There is 
>> not a big penalty and you seems to agree (your last sentence). 
>> Overriding __getitem__ gives a big penalty, that's true, but this has 
>> nothing to do with the change of the constructor in Python 2.3, right ?
>> I do not understand where the source of the confusion is (if any).
>OK, I see now what you mean. I don't agree the penalty for overriding
>__getitem__ "has nothing to dow ith change of the constructor" in the context
>of deciding whether it would be more desirable to 'enhance' dicts with a new
>'default' option or the syntactic sugar behavior. The syntacitic sugar can
>trivially be supplied by the user (``makeDict(**d): return d``), at no
>significant performance cost -- the 'default' behavior can't (and isn't just
I think I am also against the additional sugar. I'd rather be able to subclass
and, e.g., have myDict(fromSeq=['a', 1, 'b', 2]) == {'a':1, 'b':2} _unambiguously_.

Bengt Richter

More information about the Python-list mailing list