Different types of dicts with letter before the curly braces.

Steven D'Aprano steve at REMOVETHIS.cybersource.com.au
Sun Jun 14 14:59:24 CEST 2009


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




More information about the Python-list mailing list