A vote against dict(keyword=value) sugar + musing on how to do it

Bengt Richter bokr at oz.net
Fri Jun 20 20:05:43 CEST 2003

I'd rather have unambiguous use of it for subclasses of dict.

    def md(**kw):return kw
    d = dict(md(keyword=value))

is not that much work. Unambiguous simple use in subclasses is more important IMO.

If there were a way to partition arguments into multiple arg lists so __new__ could optionally
have separable lists for passing to base class constructors vs using for the
subclass __new__ vs letting __init__ maybe do something. E.g., you could separate multiple
lists with ';'

    class D(dict):
        def __new__(cls, *args, **kw; number=123,**subclass_kw):  #XXX# currently illegal
        self = dict.__new__(cls, *args, **kw)                     #XXX# shouldn't be legal unless
        self.color = subclass_kw.get('color','blue')              #     we can partition arg lists, IMO 
        self.number = number
        return self
    d1 = D(key=value, key2=value2)  #XXX# means default args for number, subclass_kw
    d2 = D(; 456, color='red')      #XXX# empty base dict, other non-default attributes

I.e., D is drop-in compatible for base-class-compatible construction calls, and has to be
different anyway for special subclass parameters, so the ';' seems ok. Or is there a hidden gotcha?

BTW, since a (name,value) tuple sequence also works, maybe it would be nice to be
able to construct such a sequence without quotes on the even-index elements. E.g., with
new keyword assoc:

    assoc(name0, val0, name1, val1, etc, etc) => [('name0',val0), ('name1',val1), ('etc', etc)]

This would provide the unquoted naming in an ordered context as well as the unordered keyword=value

Or course, in source you can spell that
    zip('name0 name1 etc'.split(),
but that ugly for longer sequences where it's harder to match the pairs, not to mention
other considerations.

Bengt Richter
(copy to python-dev at python.org, per advice in c.l.p
"Subject: a clean way to define dictionary" thread.)

Bengt Richter

More information about the Python-list mailing list