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

[M.-A. Lemburg]

On 15.12.2015 12:49, Franklin? Lee wrote:
> On Sun, Dec 13, 2015 at 5:00 AM, Jelte Fennema <me at jeltef.nl> wrote:
>> Another option would be that this syntax would not represent a list of
>> tuples but an OrderedDict. I think they both have their advantages, the list
>> of tuples would allow list operations such as `+ items` as you suggested and
>> usage of the same keys multiple times. But OrderedDict would allow simple
>> indexing directly. But it does not really matter that much since both could
>> easily be used to generate the other. OrderedDict(['1':'2']) and
>> list(['1':'2'].items()) respectively.
>>
>> I think the main case for the list of tuples is actually that you can make
>> any OrderedDict from a list of tuples, but not the other way around, since
>> duplicate keys would be removed. Which is why I like your idea for a
>> shorthand for a list of tuples better, since it covers more uses.
>>
>> One important thing to note is the discussion I already mentioned in my
>> first email. Especially this message where guide votes -100 for your syntax
>> for OrderedDict creation:
>> https://mail.python.org/pipermail/python-ideas/2009-June/004924.html
>>
>> I'm not sure why he disliked that syntax and if he still does. Or if his
>> thoughts are different when it would represent a list of tuples instead of
>> an OrderedDict.
> 
> I also wonder why he doesn't like it. I wouldn't like it if it
> represented a list of tuples.
> 
> What we have is:
> - [a, b, c] -> list = [ordered, mutable, collection]
> - {a, b, c} -> set = [unordered, mutable, collection, uniquekeys]
> - {a:x, b:y, c:z} -> dict = [unordered, mutable, mapping, uniquekeys]
> - (a, b, c) -> tuple = [ordered, immutable, collection]
> 
> It seems to me that the pattern would extend to:
> - [a:x, b:y, c:z] -> [ordered, mutable, mapping]
> - (a:x, b:y, c:z) -> [ordered, immutable, mapping]

How would the parser be able to detect these ?

Since requests to be able to access the order of values,
parameters and definitions in source code come up rather
often, perhaps it'd better to provide Python application
with a standard access mechanism to this order rather than
trying to push use of OrderedDict and the like into the
runtime, causing unnecessary performance overhead.

The parser does have access to this information in the AST
and some of it is partially copied into code object attributes,
but there's no general purpose access to the information.

Based on the source code order, you could do lots of
things, e.g. avoid hacks to map class attributes to
column definitions for ORMs, make it possible to write
OrderedDict(a=x, b=y) and have the literal order preserved,
have NamedTuple(a=x, b=y) work without additional tricks,
etc.

What's important here is that the runtime performance
would not change. The code objects would
gain some additional tuples, which store the order of
the literals used in their AST, so only the memory
consumption would increase.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Dec 16 2015)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...           http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...           http://zope.egenix.com/
________________________________________________________________________

::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/
                      http://www.malemburg.com/