[Python-Dev] defaultdict proposal round three (original) (raw)
Raymond Hettinger raymond.hettinger at verizon.net
Wed Feb 22 16:21:50 CET 2006
- Previous message: [Python-Dev] defaultdict proposal round three
- Next message: [Python-Dev] defaultdict proposal round three
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Alex]
I'd love to remove setdefault in 3.0 -- but I don't think it can be done before that: defaultfactory won't cover the occasional use cases where setdefault is called with different defaults at different locations, and, rare as those cases may be, any 2.* should not break any existing code that uses that approach.
I'm not too concerned about this one. Whenever setdefault gets deprecated , then ALL code that used it would have to be changed. If there were cases with different defaults, a regular try/except would do the job just fine (heck, it might even be faster because the won't be a wasted instantiation in the cases where the key already exists).
There may be other reasons to delay removing setdefault(), but multiple default use case isn't one of them.
An alternative is to have two possible attributes: d.defaultfactory = list or d.defaultvalue = 0 with an exception being raised when both are defined (the test is done when the attribute is created, not when the lookup is performed). I see defaultvalue as a way to get exactly the same beginner's error we already have with function defaults:
That makes sense.
I'm somewhat happy with the patch as it stands now. The only part that needs serious rethinking is putting on_missing() in regular dicts. See my other email on that subject.
Raymond
- Previous message: [Python-Dev] defaultdict proposal round three
- Next message: [Python-Dev] defaultdict proposal round three
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]