Different types of dicts with letter before the curly braces.

[kindly]

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}).

People nowadays think in terms of hashes and lists (especially with
jsons and javascript not going away} and most of my time seems to be
spent in different ways to store bits of data in memory in this way.
It also seems to be the way to think in python (an object or a class
object are just mappings themselves) Most packages that I have seen re-
implement these different container types at one point anyway. It
seems a shame they are not brought up to the top level, with
potentially new, cleverer ones that have not been thought of yet.
There will be potential to add different letters to the start when it
seems that a certain mapping pattern seems in popular use.

Am I crazy to think this is a good idea? I have not looked deeply
pythons grammer to see if it conflicts with anything, but on the
surface it looks fine.

 

[Mike Kazantsev]

Am I crazy to think this is a good idea? I have not looked deeply
pythons grammer to see if it conflicts with anything, but on the
surface it looks fine.

I'd say "on the surface it looks like perl"
I'd prefer to use dict() to declare a dict, not some mix of letters and
incomprehensible symbols, thank you.

--
Mike Kazantsev // fraggod.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAko03hsACgkQASbOZpzyXnG+0wCfZpWezoSXWSTtKzyZhMz4GjcR
xtsAn2OPrwbDqRpMKLDyM4IkNsoPCK6J
=mU8C
-----END PGP SIGNATURE-----

 

[kindly]

I'd say "on the surface it looks like perl"
I'd prefer to use dict() to declare a dict, not some mix of letters and
incomprehensible symbols, thank you.

--
Mike Kazantsev // fraggod.net

 signature.asc
< 1KViewDownload

Python already has it for strings r"foo" or u"bar". So I do not think
its going against the grain.

 

[Stefan Behnel]

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.

Stefan

 

[Mike Kazantsev]

Python already has it for strings r"foo" or u"bar". So I do not think
its going against the grain.

<flame_war_alert>

Yes, and there's other syntactic sugar like ";" (barely used),
mentioned string types, "(element,)", "%s"%var or curly braces
themselves.

Some of them might even seem as unnecessary and redundant, but they
should there to support legacy code, at least, and I don't think it's a
good idea to add any more. In fact, py3 will drop "%s"%var syntax in
favor of "{0}".format(var) and I think it's a good call.

There's only so much sugar to add before it'll transform into salt and
you'll start seeing lines like these:

s**'@z!~;()=~$x>;%x>l;$(,<x>'*e;y*%z),$;@=<x>!;h(l~;*punch jokers;halt;*;print;

I'm happy to use python because it discourages such syntax, among other things.

</flame_war_alert>

--
Mike Kazantsev // fraggod.net

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAko07XEACgkQASbOZpzyXnHp9wCffBdlzKhybGXBe430YGLRUx26
fDMAn3ZWLDLNCJHzxUJlLDXCReim+XaW
=snwQ
-----END PGP SIGNATURE-----

 

[Steven D'Aprano]

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:


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.

 

[Colin J. Williams]

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.

Stefan

This has some appeal in the light of Python 3.1's ordered dictionary.

Colin W.

 

[Diez B. Roggisch]

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.

But u"" does, as does the new bytestring-literal in Python3. So there is
precedent.

Diez

 

[Aaron Brady]

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}).

That kind of stuff is highly explosive, unfortunately. o{ }, m{ }, d
[ ], and q[ ] are just a few. But 'collections' is kind of sparse. I
expect you would also want users to be able to define their own
prefixes, no? As is, the syntax is not atrocious:

oA= OrderedDict( [ ( pair1 ), ( pair2 ) ]
oA= o{ pair1, pair2 }

At least you can still include literals, and are not restricted to per-
line additions as in C.

snip

Most packages that I have seen re-
implement these different container types at one point anyway. It
seems a shame they are not brought up to the top level, with
potentially new, cleverer ones that have not been thought of yet.

snip

Do you merely want to populate the 'collections' module, or are the
prefixes essential to your idea?

 

[kindly]

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:


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.

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.

 

[Aaron Brady]

On Jun 14, 1:59 pm, Steven D'Aprano snip
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.

Just not ahead of its /time/.

 

[Rhodri James]

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}).

-1. And before you ask, that would have been my reaction to the
'u' and 'b' string prefixes as well.

Python has perfectly good constructors for any class already, and
it's perfectly obvious what they're doing because they involve the
class name. Obfuscating this by using one character modifiers on
existing literal syntax and expecting the result to be (a) obvious
and (b) meaningful in the face of an ever-extending collection of
basic types is optimistic in the extreme. Even Perl doesn't
expect that much memory of you!