[Python-Dev] Proposal: defaultdict (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
Sat Feb 18 20:06:55 CET 2006

James Y Knight wrote:

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 defaultfactory 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.

Right. I would claim that this is an artificial example: you can't provide a HTTP_DATE value in a default_factory implementation, since you don't know what the key is.

However, you are now making up a different rationale from the one the PEP specifies: The PEP says that you need an "exact dict" so that everybody knows precisely how the dictionary behaves; instead of having to define which precise subset of the dict API is to be used.

That goal is still achieved: everybody knows that the dict might have an on_missing/default_factory implementation. So to find out whether HTTP_DATE has a value (which might be defaulted), you need to invoke d['HTTP_DATE'].

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.

Not at all. dict.getitem could always invoke arbitrary user code, through hash.

Regards, Martin

More information about the Python-Dev mailing list