[Python-Dev] Proposal: defaultdict
"Martin v. Löwis"
martin at v.loewis.de
Sat Feb 18 01:12:21 CET 2006
More information about the Python-Dev mailing list
Sat Feb 18 01:12:21 CET 2006
- Previous message: [Python-Dev] Proposal: defaultdict
- Next message: [Python-Dev] Proposal: defaultdict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ian Bicking wrote: > It is lazily incarnated for multidict, because there is no *noticeable* > side effect -- if there is any internal side effects that is an > implementation detail. However for default_factory=list, the result of > .keys(), .has_key(), and .items() changes when you do d[some_key]. That's why I think has_key and in should return True for any key. This leaves keys(), items(), and values(). From a pure point of view, they should return infinite sets. Practicality beats purity, so yes, d[k] could be considered a modifying operation. If you look carefully, you find that many access operations also have side effects. For example, .read() on a file not only returns some data, but also advances the file position. Queue.get not only returns the next item, but also removes it from the queue. Regards, Martin
- Previous message: [Python-Dev] Proposal: defaultdict
- Next message: [Python-Dev] Proposal: defaultdict
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list