[Python-Dev] Proposal: defaultdict

Sat Feb 18 19:44:01 CET 2006

On Feb 18, 2006, at 2:33 AM, Martin v. Löwis wrote:
> I don't understand. In the rationale of PEP 333, it says
> "The rationale for requiring a dictionary is to maximize portability
> between servers. The alternative would be to define some subset of a
> dictionary's methods as being the standard and portable interface."
>> That rationale is not endangered: if the environment continues to
> be a dict exactly, servers continue to be guaranteed what precise
> set of operations is available on the environment.

Yes it is endangered.
> Well, as you say: you get a KeyError if there is an error with the 
> key.
> With a default_factory, there isn't normally an error with the key.

But there should be. Consider the case of two servers. One which 
takes all the items out of the dictionary (using items()) and puts 
them in some other data structure. Then it checks if the "Date" 
header has been set. It was not, so it adds it. Consider another 
similar server which checks if the "Date" header has been set on the 
dict passed in by the user. The default_factory then makes one up. 
Different behavior due to internal implementation details of how the 
server uses the dict object, which is what the restriction to 
_exactly_ dict prevents.
Consider another server which takes the dict instance and transports 
it across thread boundaries, from the wsgi-app's thread to the main 
server thread. Because WSGI specifies that you can only use 'dict', 
and the server checked that type(obj) == dict, it is guaranteed that 
using the dict won't run thread-unsafe code. That is now broken, 
since dict.__getitem__ can now invoke arbitrary user code. That is a 
major change.
James