Different types of dicts with letter before the curly braces.

[kindly]

On Jun 14, 1:59 pm, Steven D'Aprano
<st... at REMOVETHIS.cybersource.com.au> wrote:
> Stefan Behnel wrote:
> > Hi,
>
> > this kind of stuff is commonly discussed on the python-ideas mailing list.
> > You might want to search that list and/or repost this over there.
>
> Please don't top-post here.
>
> If the OP takes this idea to python-ideas, chances are he'll be told to take
> the concept here first, for feedback, before python-ideas.
>
> More comments below:
>
> > kindly wrote:
> >> I am sure people have thought of this before, but I cant find where.
> >> I think that python should adapt a way of defining different types of
> >> mapping functions by proceeding a letter before the curly brackets.
> >> i.e   ordered = o{},  multidict = m{}  (like paste multidict).  So you
> >> could define an ordered dict by newordered = o{"llvm" : "ptyhon",
> >> "parrot" : "perl"} .  (they should also probably have there own
> >> comprehensions as well o{foo for bar in foobar}).
>
> You can do that more readably:
>
> data = OrderedDict()
> data = SortedDict()
> data = MultiDict() etc.
>
> The advantages are:
>
> * no new syntax is needed;
>
> * you can have as many different types of mappings as needed, without
> needing to change the compiler or worry about clashes between letters;
>
> * not all mapping types necessarily have the same initialiser signature;
>
> * the mapping type doesn't need to be a built-in type.
>
> The analogy with raw strings is faulty: r"" changes the way the compiler
> interprets the characters between the quotes, it doesn't create a different
> type of object.
>
> There's nothing explicitly *wrong* with the idea of o{} m{} etc for a
> *small* number of built-in mapping types. If ordered dicts (say) ever
> become built-ins, rather than a type that you have to import from a module,
> then maybe we'll be looking for syntax for them, in which case there's
> worse ideas than o{}. But even then, a disadvantage would be that it's
> awfully perlish. There's already two uses for {}, namely dicts and sets,
> and I don't know that adding a third or more is a good idea.
>
> --
> Steven

Thank you all for your feedback.  I have never actually used perl, but
I imagine if I did, I imagine I would have more disgust at the suger.

I think my point is more that I think python should consider having
more useful top level data structures and less to do with how they are
created.  There has been a big shift in the way people pass around
structures and this is mainly due to the dict(hash) type, that python
uses so well.  I am glad the ordered dict will be in 2.7 and 3.1. I
was just imagining what would be the next step in definition of
structures. New languages like clojure have adopted the dict as top
level.  I imagine immutable/thread safe/transactional dicts to be
around soon in other languages to help with concurrency.  It would be
nice if python was ahead of the game in this.