Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #2992 > unrolled thread

[Feature Request] dict.setdefault()

Back to article view | Back to comp.lang.python

Contents

  [Feature Request] dict.setdefault() rantingrick <rantingrick@gmail.com> - 2011-04-11 14:35 -0700
    Re: [Feature Request] dict.setdefault() Westley Martínez <anikom15@gmail.com> - 2011-04-11 15:16 -0700
    Re: [Feature Request] dict.setdefault() MRAB <python@mrabarnett.plus.com> - 2011-04-11 23:41 +0100
      Re: dict.setdefault() rantingrick <rantingrick@gmail.com> - 2011-04-11 19:58 -0700
        Re: dict.setdefault() Westley Martínez <anikom15@gmail.com> - 2011-04-12 07:02 -0700
        Re: dict.setdefault() Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2011-04-25 16:23 +0200
    Re: [Feature Request] dict.setdefault() Chris Angelico <rosuav@gmail.com> - 2011-04-12 08:44 +1000
    Re: dict.setdefault() Raymond Hettinger <python@rcn.com> - 2011-04-11 15:49 -0700
    Re: [Feature Request] dict.setdefault() Chris Rebert <clp2@rebertia.com> - 2011-04-11 15:53 -0700
    Re: [Feature Request] dict.setdefault() MRAB <python@mrabarnett.plus.com> - 2011-04-11 23:59 +0100
    Re: [Feature Request] dict.setdefault() Tim Chase <python.list@tim.thechases.com> - 2011-04-11 18:25 -0500
      Re: dict.setdefault() Raymond Hettinger <python@rcn.com> - 2011-04-11 17:17 -0700

#2992 — [Feature Request] dict.setdefault()

setdefault should take **kw args in the case of needing to set
multiple defaults at one time. I would even settle for an *arg list if
i had to. Anything is better than...

d.setdefault(blah, blah)
d.setdefault(blah, blah)
d.setdefault(blah, blah)
d.setdefault(blah, blah)
if blah is not blah:
    d.setdefault(blah, blah)

...nuff said.

PS: And to counter the very *extemely* likely chance of some smart
arse responses
  * YES, i know i could create my own setdefault method but that is
not the point.
  * I know we are under the moratorium but someone had to mention it,

--rr

[toc] | [next] | [standalone]

#2994

On Mon, 2011-04-11 at 14:35 -0700, rantingrick wrote:
> setdefault should take **kw args in the case of needing to set
> multiple defaults at one time. I would even settle for an *arg list if
> i had to. Anything is better than...
> 
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> if blah is not blah:
>     d.setdefault(blah, blah)
> 
> ...nuff said.
> 
> PS: And to counter the very *extemely* likely chance of some smart
> arse responses
>   * YES, i know i could create my own setdefault method but that is
> not the point.
>   * I know we are under the moratorium but someone had to mention it,
> 
> --rr

Go to bugs.python.org

[toc] | [prev] | [next] | [standalone]

#2996

On 11/04/2011 23:16, Westley Martínez wrote:
> On Mon, 2011-04-11 at 14:35 -0700, rantingrick wrote:
>> setdefault should take **kw args in the case of needing to set
>> multiple defaults at one time. I would even settle for an *arg list if
>> i had to. Anything is better than...
>>
>> d.setdefault(blah, blah)
>> d.setdefault(blah, blah)
>> d.setdefault(blah, blah)
>> d.setdefault(blah, blah)
>> if blah is not blah:
>>      d.setdefault(blah, blah)
>>
>> ...nuff said.
>>
>> PS: And to counter the very *extemely* likely chance of some smart
>> arse responses
>>    * YES, i know i could create my own setdefault method but that is
>> not the point.
>>    * I know we are under the moratorium but someone had to mention it,
>>
>> --rr
>
> Go to bugs.python.org
>
I'm not sure that "setdefault" should take **kw args for this because
of its existing argument structure (key + optional value).

A new method like "updatedefault" may be better, IMHO. It would act
like "update" except that it wouldn't overwrite existing values.

[toc] | [prev] | [next] | [standalone]

#3020 — Re: dict.setdefault()

On Apr 11, 5:41 pm, MRAB <pyt...@mrabarnett.plus.com> wrote:

> A new method like "updatedefault" may be better, IMHO. It would act
> like "update" except that it wouldn't overwrite existing values.

That's sounds good MRAB! After you mentioned this i had an epiphany...
why not just add an extra argument to dict.update?

>>> dict.update(D, clobberexistingkeys=False)

[toc] | [prev] | [next] | [standalone]

#3050 — Re: dict.setdefault()

On Mon, 2011-04-11 at 19:58 -0700, rantingrick wrote:
> <snip>
> 
> >>> dict.update(D, cobblerexistingkeys=False)

Fix'd
Much yummier now.

[toc] | [prev] | [next] | [standalone]

#3983 — Re: dict.setdefault()

Am 12.04.2011 04:58, schrieb rantingrick:

> That's sounds good MRAB! After you mentioned this i had an epiphany...
> why not just add an extra argument to dict.update?
>
>>>> dict.update(D, clobberexistingkeys=False)

This is AFAICS inconsistent to the possibility to do dict.update(a, 
k1=v1, k2=v2).

Then you cannot set the key clobberexistingvalues to False via the 
update method any longer...


Thomas

[toc] | [prev] | [next] | [standalone]

#2997

On Tue, Apr 12, 2011 at 8:41 AM, MRAB <python@mrabarnett.plus.com> wrote:
> I'm not sure that "setdefault" should take **kw args for this because
> of its existing argument structure (key + optional value).
>
> A new method like "updatedefault" may be better, IMHO. It would act
> like "update" except that it wouldn't overwrite existing values.

Wouldn't x.updatedefault(y) be pretty much y.update(x) ?

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#2999 — Re: dict.setdefault()

On Apr 11, 2:35 pm, rantingrick <rantingr...@gmail.com> wrote:
> setdefault should take **kw args in the case of needing to set
> multiple defaults at one time. I would even settle for an *arg list if
> i had to. Anything is better than...
>
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> if blah is not blah:
>     d.setdefault(blah, blah)

I hate to feed a troll, but I'm curious when you see that pattern of
calls.  The typical use case always makes immediate use of the value
returned by setdefault():

   d.setdefault(key, []).append()

The pattern you've shown would more typically be expressed like this:

   for key in multiple_defaults.items():
       if key, default_value not in d:
           d[key] = default_value

Or people sometimes use updates to get the same effect:

   result = multiple_defaults.copy()
   result.update(d)

Another approach is to use something like ChainMap() which has been
added to Python 3.3. http://docs.python.org/dev/library/collections.html#collections.ChainMap

   result = ChainMap(d, multiple_defaults)


Raymond

[toc] | [prev] | [next] | [standalone]

#3000

On Mon, Apr 11, 2011 at 2:35 PM, rantingrick <rantingrick@gmail.com> wrote:
>
> setdefault should take **kw args in the case of needing to set
> multiple defaults at one time. I would even settle for an *arg list if
> i had to.

What would the return value be? dict.setdefault() doesn't currently
just return None you know.

> Anything is better than...
>
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> d.setdefault(blah, blah)
> if blah is not blah:
>    d.setdefault(blah, blah)

The redundancy is easily removed:
defaults = {blah: blah, blah: blah, blah: blah, blah: blah}
defaults.update(d) # clobber defaults with specified vals
d = defaults # swap in, assuming not aliased
# if aliased, then instead:
# d.clear()
# d.update(defaults)
if blah is not blah:
    d.setdefault(blah, blah)

Cheers,
Chris
--
http://blog.rebertia.com

[toc] | [prev] | [next] | [standalone]

#3002

On 11/04/2011 23:44, Chris Angelico wrote:
> On Tue, Apr 12, 2011 at 8:41 AM, MRAB<python@mrabarnett.plus.com>  wrote:
>> I'm not sure that "setdefault" should take **kw args for this because
>> of its existing argument structure (key + optional value).
>>
>> A new method like "updatedefault" may be better, IMHO. It would act
>> like "update" except that it wouldn't overwrite existing values.
>
> Wouldn't x.updatedefault(y) be pretty much y.update(x) ?
>
I suppose it would, except that it wouldn't be in-place as such, and it
wouldn't be as efficient if you're wanting to default only a few
entries in a larger dict.

[toc] | [prev] | [next] | [standalone]

#3005

On 04/11/2011 05:44 PM, Chris Angelico wrote:
> On Tue, Apr 12, 2011 at 8:41 AM, MRAB<python@mrabarnett.plus.com>  wrote:
>> I'm not sure that "setdefault" should take **kw args for this because
>> of its existing argument structure (key + optional value).
>>
>> A new method like "updatedefault" may be better, IMHO. It would act
>> like "update" except that it wouldn't overwrite existing values.
>
> Wouldn't x.updatedefault(y) be pretty much y.update(x) ?

As I understand, the difference would be the following pseudocode:

  def update(self, d):
    for k,v in dict(d).iteritems():
      self[k] = v

  def updatedefault(self, d={}, **kwargs):
    for k,v in chain(
       dict(d).iteritems(),
       kwargs.iteritems()
       ):
      # MRAB's comment about "wouldn't overwrite existing"
      if k not in self:
        self[k] = v

My concern with the initial request is that dict.setdefault() 
already returns the (existent or defaulted) value, so you can do 
things like

   d.setdefault(my_key, []).append(item)

If you allow it to take multiple kwargs, what would the return 
value be (positionality of kwargs is lost, so returning a tuple 
wouldn't be readily possible)?

Finally, if it were added, I'd call it something like merge()

-tkc

[toc] | [prev] | [next] | [standalone]

#3006 — Re: dict.setdefault()

On Apr 11, 4:25 pm, Tim Chase <python.l...@tim.thechases.com> wrote:
> Finally, if it were added, I'd call it something like merge()

Guido rejected merge() a long time ago.

Anyway, there is a new ChainMap() tool in the collections module for
Py3.3 that should address a number of use cases for handling default
values.


Raymond

twitter: @raymondh

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web