> Just to make sure, why not move sort_repr=False out of the parameter > list and into the code body. Good idea. It can be a non-public class variable. > [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. I don't think François was stating that the order was only dependent on the inserted keys. I believe he was merely referring to the fact that the order doesn't change as long as you don't mutate a dict, and that it's the same for items(), keys(), values(), iterators, and display order. There's no reason to keep that hidden, and I believe it's documented (though François didn't find it). --Guido van Rossum (home page: http://www.python.org/~guido/)
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