This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lukasz.langa
Recipients eric.araujo, eric.smith, holdenweb, lukasz.langa, michael.foord, rhettinger
Date 2010-11-25.19:44:11
SpamBayes Score 1.4988011e-15
Marked as misclassified No
Message-id <1290714257.34.0.470557756443.issue10533@psf.upfronthosting.co.za>
In-reply-to
Content
A couple of points:

1. Eric's proposal is what I had in mind with the `fallbackdict' idea.
2. I'm also reluctant to add more variants to the standard library. Then again if it contained a `fallbackdict' I wouldn't probably ever use `defaultdict' again. How often do you need to provide a factory?
3. Naming the other variant `defaultdict_const', `defaultdict_value', `defaultdict_whatever' beats the purpose because it's actually more characters to type than `defaultdict(lambda:', especially when you count the longer import name.
4. I cannot come up with another typical integer value that would be useful, then again I've used "", [] and set() numerous times. Adding zerodict, stringdict, listdict, setdict is obviously absurd.
5. The discussion started on Twitter amongst a couple of core devs and __missing__ didn't appear to be the one obvious way to anyone.
6. Of course I'm in no position to reject Guido's design on anything. Then again even `defaultdict(lambda:' is simply so much shorter than subclassing dict.

To sum up: if you don't find the idea of adding `fallbackdict' (possibly with an different *short* name) worth it, then I'm +1 on correcting the docs in terms of __missing__ and leaving the implementation as is.
History
Date User Action Args
2010-11-25 19:44:17lukasz.langasetrecipients: + lukasz.langa, rhettinger, holdenweb, eric.smith, eric.araujo, michael.foord
2010-11-25 19:44:17lukasz.langasetmessageid: <1290714257.34.0.470557756443.issue10533@psf.upfronthosting.co.za>
2010-11-25 19:44:11lukasz.langalinkissue10533 messages
2010-11-25 19:44:11lukasz.langacreate