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

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