John Williams wrote:
> The other use case I have is for dealing with data where the iteration
> order doesn't matter to the program but it does matter to users. For
> instance, consider the ConfigParser's write method. Any ordering of
> values in the output is functionally equivalent, but the original data
> is likely to have come from a file that was arranged in some meaningful
> order, and it would be nice to preserve that order, especially if it can
> be done with no extra effort.
That is a good example, IMO. But then, in the specific case, the
dictionary for each section is created deeply inside ConfigParser,
with the lines
cursect = {'__name__': sectname}
self._sections[sectname] = cursect
So this uses a builtin dict, and there is no easy way to override it
for the application.
Of course, given your reasoning, ConfigParser *should* use an
OrderedDictionary (probably both for cursect and for self._sections),
in which case this would all be transparent to the application.
Regards,
Martin
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