[Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered (original) (raw)

Terry Reedy tjreedy at udel.edu
Wed Sep 14 15:02:55 EDT 2016

On 9/14/2016 9:33 AM, INADA Naoki wrote:

I mean using a compact representation, if not an ordered one. I have no particular usecase in mind. As far as I understand the compact implementation, sets can do it just as well. The original discussion proposed trying to implement it for sets first. Like dict, they would (probably) use less memory, and would usually have a more readable (i.e. less jarring to read) print order. I'll improve OrderedDict after dict in 3.6 is stable enough. Then, I'll do same to sets. While compact ordered split dict is very hard to implement right, OrderedDict and set must be easier than dict.

Frozensets, and even more, sets, have lots of operations that dicts do not. Making sets more compact without slowing down the various operations should be an interesting challenge.

Insert order is not meaningful for at least some of the operations. Moreover, I believe repeated inserts and deletions are much more common for sets than dicts. So I think that any initial ordering should be considered a side-effect and documented as such. The operations would then be optimized for speed and compactness without regard to ordering. This might mean keeping a linked list of free slots so slots can be reused and costly compaction avoided as much and for long as possible.

We already have compact mutable collection types that can be kept insert-ordered if one chooses -- lists and collections.deque -- and they are not limited to hashables. Before sets were added, either lists or dicts with None values were used as sets. The latter is obsolete but lists are still sometimes used for their generality, as in a set of lists. We now also have enums for certain small frozensets where the set opertions are not needed.

-- Terry Jan Reedy

More information about the Python-Dev mailing list