[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