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

[Jelte Fennema]

After thinking some more, I think you are right in saying that it would
make more sense to let it represent an OrderedDict directly. Mostly because
the mutability suggested by the square brackets. And also a bit because I'm
not sure when a mapping that maps multiple values to the same key is
actually useful.

Secondly, I think your idea for namedtuple literals is great. This would be
really useful in the namedtuple use case where you want to return multiple
values from a function, but you want to be clear in what these values
actually are. I think this would need to generate some kind of anonymous
named tuple class though, since it would make no sense to have to create a
new class when using a literal like this.

I would really like to hear Guido's response to these ideas. Since he
disliked the idea so much in the past and I can't find a reference to his
reasoning.

Jelte

PS. Seeing as we're cleary drifting from the original topic of this thread,
would it be a good idea if a new one would be created with these new ideas
in mind?

On 15 December 2015 at 12:49, Franklin? Lee <leewangzhong+python at gmail.com>
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]
>
> The first one is ALMOST OrderedDict, except that it has unique keys.
> The second is ALMOST namedtuple, except that it:
> - doesn't allow duplicate keys
> - doesn't allow indexing by keys (though this can change)
> - doesn't allow arbitrary key type (and we don't want ints allowed as keys)
> - needs a name and a type
>
> If we add the rule that a mapping literal's type should have unique
> keys, then [a:x] -> OrderedDict fits the pattern. But [a:x] => [(a,x)]
> doesn't.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151215/eacda403/attachment.html>