Title: dict.update should take a 2-tuple sequence like dict.__init_
Type: Stage:
Components: Interpreter Core Versions: Python 2.4
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: bob.ippolito, gvanrossum, loewis, nnorwitz, rhettinger
Priority: normal Keywords: patch

Created on 2004-02-26 01:05 by bob.ippolito, last changed 2005-01-29 13:36 by loewis. This issue is now closed.

File name Uploaded Description Edit
dictupdateseq.patch bob.ippolito, 2004-02-26 01:05 PyDict_Update should take a 2-tuple sequence
dict.diff rhettinger, 2004-02-29 22:39 Use same underying code for __init__() and update()
Messages (12)
msg45416 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-26 01:05
This patch allows:
    d = {}
    d.update([(1,2), (3,4)])

The current way to do it is (unfortunately):
    d = {}
    d.update(dict([(1,2), (3,4)]))
msg45417 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-02-27 00:53
Logged In: YES 

Though not exactly obvious, this functionality and more is
available through dict.__init__().

Since it would be a change to an important API, referring to
Guido for pronouncement.  My vote is -0.
msg45418 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-27 01:02
Logged In: YES 

The (__doc__) documentation doesn't cover that case.. it says "new..." 
for every signature of dict.__init__.

Attempting to call __init__ multiple times isn't really an obvious thing to 
do, because it almost never does what you want.  I would chalk that up 
to an implementation detail of dict, not intended behavior :)
msg45419 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2004-02-27 01:28
Logged In: YES 

-1 here
msg45420 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-27 01:31
Logged In: YES 

Well, I think somedict.update(generatorexpression) would be awfully nice 
to have :)
msg45421 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2004-02-27 02:08
Logged In: YES 

Sorry, Bob, I'm rejecting this one.  Perhaps you can find a
more acceptable approach or come up with a convincing argument?
msg45422 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-02-29 21:12
Logged In: YES 

Guido, after some discussion on comp.lang.python, I would
like to re-open this one.

I'm +1 on an alternate patch with a simpler approach that
defines dict.update to be the same as dict.__init__().

This reduces to total amount of code and is easy to learn
because it builds off of existing knowledge for calling the

In terms of functionality, it is more readable, faster, and
more memory efficient than explicity constructing an
intermediate dictionary for the update.  Also, as Bob points
out, it works nicely with genexps.

If approved, please assign back to me for the revised
implementation, unittests, and doc updates.
msg45423 - (view) Author: Bob Ippolito (bob.ippolito) * (Python committer) Date: 2004-02-29 21:21
Logged In: YES 

Thanks Raymond, I was not aware of dict.__init__'s updating capabilities 
when I wrote the patch, and I agree that making the two equivalent is 
indeed the right solution.  Implementation wise, I believe the right 
answer would be to refactor the code such that dict.__init__ calls (the 
new) dict.update, not vice versa, for clarity's sake.

My patch was just the first thing that came to mind when I ran into yet 
another situation where I wanted to update a dictionary with a key,value 
msg45424 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2004-03-01 00:41
Logged In: YES 

I guess that unifying the two makes sense, and defining
__init__ as calling (or being) update makes sense.
msg45425 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-03-04 04:56
Logged In: YES 

If there are no objections, I will approve this one.
msg45426 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2004-03-04 08:35
Logged In: YES 

Okay, just saw Guido's assent.

Marking as approved and applying as Objects/dictobject.c 2.152.
Updated unittests, documentation, and other mapping interfaces.

Bob, thanks for championing this one past the initial
resistance.  It was a good idea.
msg45427 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-01-29 13:36
Logged In: YES 

Removing update from os.environ turned out to be a bad idea,
as putenv was not called anymore. I have reverted the
removal and reimplemented update in 1.85 1.29
NEWS 1.1235
Date User Action Args
2004-02-26 01:05:14bob.ippolitocreate