[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
> change.

Not at all. dict.__getitem__ could always invoke arbitrary user code,
through __hash__.


More information about the Python-Dev mailing list