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__. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
