> d = {}
> ...do some stuff... [A]
> d.factory = factory_func
> ...do some more stuff... [B]
>
> The meaning of d[k] is significantly different in section A than it was
> in section B.
For most any reasonable program, previous lines of execution determine
the context of later lines. Saying that d[k] in section A is different
than d[k] in section B is an assumption that all people make when
writing useful programs in most languages.
We can say the same thing about the meaning of d[1] in sections A and B
of the following snippet.
d = {}
d[1] = 1
#A
del d[1]
#B
While the above it is not good programming style, it does highlight the
fact that the existance of dict.factory (or any equivalent behavior)
doesn't remove meaning or expressiveness of the statements using,
preceeding, or following it.
Certainly dict.factory ends up overlapping with a portion of the
functionality of dict.setdefault, but it has the potential for reducing
the peppering of dict.setdefault(key, value) in some programs.
As an aside, when I first started using Python, I thought (before using
it) that dict.setdefault had the behavior of what dict.factory is
suggested as having now.
- Josiah
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