[Python-ideas] Dict literal use for custom dict classes

[Andrew Barnert]

On Dec 16, 2015, at 15:17, Nathaniel Smith <njs at pobox.com> wrote:
> 
>> On Wed, Dec 16, 2015 at 10:47 AM, Mike Miller <python-ideas at mgmiller.net> wrote:
>> 
>>> On 2015-12-15 11:02, Paul Moore wrote:
>>> 
>>> while it's a bit too special case on its own, one
>>> possibility would be to have
>>> 
>>>     callable{k1: v1, k2: v2, ...}
>>> 
>>> be syntactic sugar for
>>> 
>>>     callable([(k1, k1), (k2, v2), ...])
>> 
>> 
>> Very interesting... I've faced the issue several times over the years when
>> I've wanted to unpack values into a function call in an ordered manner (but
>> it hasn't been available).  Perhaps::
>> 
>>    callable{**odict}
>> 
>> In fact with callables I'd even go so far as wish that ordered unpacking was
>> the default somehow, though I guess that probably isn't possible due to
>> history.
> 
> That's not so clear, actually! It turns out that PyPy was able to make
> their regular 'dict' implementation ordered, while at the same time
> making it faster and more memory-efficient compared to their previous
> (CPython-like) implementation:
> 
>  http://morepypy.blogspot.com/2015/01/faster-more-memory-efficient-and-more.html
> 
> So in PyPy all these issues are automatically solved for free. The
> $1e6-question these other proposals have to answer is, why not do what
> PyPy did?

You don't even need that; a dict that's ordered as long as you never delete from it or expand it after initial creation is good enough, and that may be simpler. (For example, Raymond Hettinger's two-table prototype guarantees this much, even though it isn't order-preserving on deletes, and it should be faster and more compact than the current design, although I don't know if anyone's proven that part, and it's the "dead-simple once you see it" kind of brilliant rather than the deep-magic kind.)

The bigger problem is that any other Python implementation that uses some native (Java, .NET, JS, ...) structure to back its Python dicts will obviously need to either change to a different one or use a two-table structure like Raymond's--which may be a pessimization rather than an optimization and/or may break whatever thread-safety guarantees they were relying on. So, you'd need to make sure there's a good answer for every major implementation out there before changing the language to require them all to do it.

Of course we'd also need to require that **kw unpacking happens in iteration order, and **kw collecting collects the keywords in the order passed, but both of those should be easy. (They may still be changes--an implementation might, say, reverse the order for a slight simplification or something--but they should be trivial compare to finding an order-preserving-at-least-until-mutation structure.)

But assuming those are all reasonable, it seems like the easiest solution to the problem.