«

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.

On Sun, 14 Jun 2009 04:02:47 -0700 (PDT)
kindly <> wrote:

> 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+0wCfZpWezoSXWS TtKzyZhMz4GjcR
xtsAn2OPrwbDqRpMKLDyM4IkNsoPCK6J
=mU8C
-----END PGP SIGNATURE-----

On Jun 14, 12:25*pm, Mike Kazantsev <mk.frag...@gmail.com> wrote:
> On Sun, 14 Jun 2009 04:02:47 -0700 (PDT)
>
> kindly <kin...@gmail.com> wrote:
> > 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
>
> *signature.asc
> < 1KViewDownload

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

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

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

On Sun, 14 Jun 2009 04:36:17 -0700 (PDT)
kindly <> wrote:

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

iEYEARECAAYFAko07XEACgkQASbOZpzyXnHp9wCffBdlzKhybG XBe430YGLRUx26
fDMAn3ZWLDLNCJHzxUJlLDXCReim+XaW
=snwQ
-----END PGP SIGNATURE-----

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

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

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

Colin W.

> 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

On Jun 14, 4:02*am, kindly <kin...@gmail.com> 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}).

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?

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