| msg45416 - (view) |
Author: Bob Ippolito (bob.ippolito) *  |
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) * |
Date: 2004-02-27 00:53 |
| 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. |
|
|
| msg45418 - (view) |
Author: Bob Ippolito (bob.ippolito) * |
Date: 2004-02-27 01:02 |
| 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 :) |
|
|
| msg45419 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2004-02-27 01:28 |
| Logged In: YES user_id=6380 -1 here |
|
|
| msg45420 - (view) |
Author: Bob Ippolito (bob.ippolito) * |
Date: 2004-02-27 01:31 |
| Logged In: YES user_id=139309 Well, I think somedict.update(generatorexpression) would be awfully nice to have :) |
|
|
| msg45421 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2004-02-27 02:08 |
| 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? |
|
|
| msg45422 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2004-02-29 21:12 |
| 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. |
|
|
| msg45423 - (view) |
Author: Bob Ippolito (bob.ippolito) * |
Date: 2004-02-29 21:21 |
| 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. |
|
|
| msg45424 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2004-03-01 00:41 |
| Logged In: YES user_id=6380 I guess that unifying the two makes sense, and defining __init__ as calling (or being) update makes sense. |
|
|
| msg45425 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2004-03-04 04:56 |
| Logged In: YES user_id=80475 If there are no objections, I will approve this one. |
|
|
| msg45426 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2004-03-04 08:35 |
| 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. |
|
|
| msg45427 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2005-01-29 13:36 |
| 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 |
|
|