This article:

http://mail.python.org/pipermail/python-dev/2006-February/061748.html

describes dict.getdefault() as a replacement for
dict.setdefault().  Here is a candidate implementation.

Logged In: YES 
user_id=34209

Super, looks great, excellent cut-and-paste work there, Barry. Let's check this in 
while Guido is too busy talking to people at Pycon to notice. ;-)

Logged In: YES 
user_id=849994

I'm not entirely sure how to explain to newcomers what the
hell the difference between getdefault and setdefault is,
and what their names have to do with it.

Logged In: YES 
user_id=80475

-1 on adding this method.  

The new defaultdict goes a long way toward meeting many 
needs.

IMO, the granular case is better met with a simple 
try/except.  Please, let's not bloat the dict API just 
because we can.

The original setdefault was problematic not just because 
of its name and unnecessary instantiations.  There were 
also readability issues from jamming too much on one line.

Also, one we've added __missing__ support and defaultdict, 
the environment has become more crowded with variations on 
solutions to a similar problems.  Adding too many 
solutions makes all of them harder to choose from.  The 
mapping API is too important to bloat with this method -- 
we need to be going the other direction (removing has_key 
and setdefault).

Assigning to Guido for pronouncement.

Logged In: YES 
user_id=6380

Sorry, no go. Yet another method with subtly different
semantics is not helping.

My expectation is that collections.defaultdict will address
the need adequately (and it addresses a number of other
needs that getdefault() doesn't address).  If not, let's
revisit this in 2.6.