[Python-Dev] defaultdict proposal round three
Raymond Hettinger
raymond.hettinger at verizon.net
Wed Feb 22 16:21:50 CET 2006
More information about the Python-Dev mailing list
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: default_factory 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.default_factory = list >> or >> d.default_value = 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 default_value 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 ]
More information about the Python-Dev mailing list