RetroSearch Browse

Wed Feb 22 16:21:50 CET 2006 · https://mail.python.org/pipermail/python-dev/2006-February/061707.html

[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 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-February/061707.html below:

[Python-Dev] defaultdict proposal round three