Different types of dicts with letter before the curly braces.

kindly kindly at gmail.com
Sun Jun 14 15:30:59 CEST 2009


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.






More information about the Python-list mailing list