Anyone remember why setdefault's second argument is optional?
>>> d = {}
>>> d.setdefault(666)
>>> d
{666: None}
just doesn't seem useful. In fact, it's so silly that someone calling
setdefault with just one arg seems far more likely to have a bug in
their code than to get an outcome they actually wanted. Haven't found
any 1-arg uses of setdefault() either, except for test code verifying
that you _can_ omit the second arg.
This came up in ZODB-land, where someone volunteered to add
setdefault() to BTrees. Some flavors of BTrees are specialized to
hold integer or float values, and then setting None as a value is
impossible. I resolved it there by making BTree.setdefault() require
both arguments. It was a surprise to me that dict.setdefault() didn't
also require both.
If there isn't a sane use case for leaving the second argument out,
I'd like to drop the possibility in P3K (assuming setdefault()
survives).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4