[GvR] > > But for now, I'll just leave sort_repr=False in. [FP] > As long as users do not discover it, they will not use it! :-) Just to make sure, why not move sort_repr=False out of the parameter list and into the code body. [FP] > By the way (this was discussed on Python list a while ago), it might > be worth stressing in the official documentation that dicts, and maybe > Sets as well, all have a "natural" iteration order which remains fixed at > least while the dict or Set does not loose or acquire keys, and that this > same fixed order is used for .items(), .keys(), .values(), and all three > .iter* flavours. It is sometimes useful being able to rely on this fact, > especially if Python clearly commits itself through the documentation. Just like stability for the new list.sort(), this promise ought to remain a hidden, undocumented implementation detail. Because of collision resolution, the "natural" order can vary depending on the order that the keys are inserted. While the ordering stays constant until there is a change, it is fragile and could be changed by a resize operation even if the keys remain the same. Let's keep the options open here in case someday we want GC or a memory manager to rebuild the dictionary at an arbitrary time. Raymond Hettinger
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