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)]))

Logged In: YES 
user_id=80475

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.

Logged In: YES 
user_id=139309

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 :)

Logged In: YES 
user_id=6380

-1 here

Logged In: YES 
user_id=139309

Well, I think somedict.update(generatorexpression) would be awfully nice 
to have :)

Logged In: YES 
user_id=33168

Sorry, Bob, I'm rejecting this one.  Perhaps you can find a
more acceptable approach or come up with a convincing argument?

Logged In: YES 
user_id=80475

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
constructor.

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.

Logged In: YES 
user_id=139309

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 
sequence.

Logged In: YES 
user_id=6380

I guess that unifying the two makes sense, and defining
__init__ as calling (or being) update makes sense.

Logged In: YES 
user_id=80475

If there are no objections, I will approve this one.

Logged In: YES 
user_id=80475

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.

Logged In: YES 
user_id=21627

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

os.py 1.85
test_os.py 1.29
NEWS 1.1235