[Python-Dev] Proposal: defaultdict
"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 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.
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
Not at all. dict.__getitem__ could always invoke arbitrary user code,
More information about the Python-Dev