We surely need a real-world example of a problem this solves. Without something dramatically compelling, I can't imagine that your proposed syntax will have a ghost of a chance of being taken seriously.

On Tue, Jun 16, 2009 at 9:55 AM, Ben Finneyben+python@benfinney.id.au wrote:

Carl Johnson cmjohnson.mailinglist@gmail.com writes:

...

we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal.

What do you mean by “more explicit”? The existing set literal syntax is quite explicit.

...

s{} could be the empty set, o{} could be an empty odict, and we could leave {} alone as the form for dicts. So, an odict literal would look like o{'a':'1', 'b':'2', 'c':'3'} instead of OrderedDict([('a', '1'), ('b', '2'), ('c', '3')]). And the set {'a', 'c', 'b'} could (optionally?) have a little s{'a', 'c', 'b'} to make it more explicit that this is a set, not a dict.

I don't think that word “explicit” means what you think it means.

...

So what do people think? Is this too ugly to do?

You haven't really identified a problem that is solved by this. And yes, I think it's significantly uglier than the existing syntax.

...

Does it confuse users who are used to C-style braces? Or is it a logical extension of the b"", r"", etc. system that could help make things follow EIBI better?

(Presuming you mean “EIBTI”, for “Explicit Is Better Than Implicit”.)

I don't see anything implicit about the following forms:

set()    OrderedDict()    frozenset()

So I think you're trying to achieve something else other than “explicit”, but I don't know what it is, nor what the problem is that needs addressing.

--  \           “Never express yourself more clearly than you are able to |  `\                                               think.” —Niels Bohr | _o__)                                                                  | Ben Finney

---

Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Ron Adam wrote:

Ben Finney wrote:

...

Carl Johnson cmjohnson.mailinglist@gmail.com writes:

...

we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal.

What do you mean by “more explicit”? The existing set literal syntax is quite explicit.

...

s{} could be the empty set, o{} could be an empty odict, and we could leave {} alone as the form for dicts. So, an odict literal would look like o{'a':'1', 'b':'2', 'c':'3'} instead of OrderedDict([('a', '1'), ('b', '2'), ('c', '3')]). And the set {'a', 'c', 'b'} could (optionally?) have a little s{'a', 'c', 'b'} to make it more explicit that this is a set, not a dict.

I don't think that word “explicit” means what you think it means.

I think Carl is thinking that it is more concise and easier to read.

When you read OrderedDict([('a', '1'),('b', '2'), ('c', '3')]), your mind is parsing *Ordered Dictionary from list of these three tuples*.

Whebn you read *o{'a':'1', 'b':'2', 'c':'3'}*, your mind does not have the extra noise of converting the argument list of the constructor.

How about ['a':'1', 'b':'2', 'c':'3']?

I think it really depends on how often ordered dictionaries literals will be used weather or not it is worth doing. It also uses about 30% to 50% less keystrokes.

Ideally we would have [...] for ordered and {...} for unordered, with ':' if it's keyed:

[] ordered, value (list) [:] ordered, key+value (odict) {} unordered, value (set) {:} unordered, key+value (dict)

It's too late to change that in Python 3.x, so it would have to be:

[] ordered, value (list) [:] ordered, key+value (odict) {,} unordered, value (set) {} unordered, key+value (dict)

MRAB wrote:

Ron Adam wrote:

...

Ben Finney wrote:

...

Carl Johnson cmjohnson.mailinglist@gmail.com writes:

...

we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal.

What do you mean by “more explicit”? The existing set literal syntax is quite explicit.

...

s{} could be the empty set, o{} could be an empty odict, and we could leave {} alone as the form for dicts. So, an odict literal would look like o{'a':'1', 'b':'2', 'c':'3'} instead of OrderedDict([('a', '1'), ('b', '2'), ('c', '3')]). And the set {'a', 'c', 'b'} could (optionally?) have a little s{'a', 'c', 'b'} to make it more explicit that this is a set, not a dict.

I don't think that word “explicit” means what you think it means.

I think Carl is thinking that it is more concise and easier to read.

When you read OrderedDict([('a', '1'),('b', '2'), ('c', '3')]), your mind is parsing *Ordered Dictionary from list of these three tuples*.

Whebn you read *o{'a':'1', 'b':'2', 'c':'3'}*, your mind does not have the extra noise of converting the argument list of the constructor.

How about ['a':'1', 'b':'2', 'c':'3']?

...

I think it really depends on how often ordered dictionaries literals will be used weather or not it is worth doing. It also uses about 30% to 50% less keystrokes.

Ideally we would have [...] for ordered and {...} for unordered, with ':' if it's keyed:

[]  ordered,   value      (list)
[:] ordered,   key+value  (odict)
{}  unordered, value      (set)
{:} unordered, key+value  (dict)

It's too late to change that in Python 3.x, so it would have to be:

[]  ordered,   value      (list)
[:] ordered,   key+value  (odict)
{,} unordered, value      (set)
{}  unordered, key+value  (dict)

---

Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedytjreedy@udel.edu wrote:

Carl Johnson wrote:

...

I thought of this in the shower. It might not be a good idea, but I'd like to hear what other people think. On analogy with b"", r"", etc. we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal. s{} could be the empty set, o{} could be an empty odict, and we could leave {} alone as the form for dicts. So, an odict literal would look like o{'a':'1', 'b':'2', 'c':'3'} instead of OrderedDict([('a', '1'), ('b', '2'), ('c', '3')]). And the set {'a', 'c', 'b'} could (optionally?) have a little s{'a', 'c', 'b'} to make it more explicit that this is a set, not a dict.

I suppose if we wanted to get crazy, we could also have a frozenset literal, fs{}…

So what do people think? Is this too ugly to do? Does it confuse users who are used to C-style braces? Or is it a logical extension of the b"", r"", etc. system that could help make things follow EIBI better?

-1 from me.

I consider b"" and r"" to be hacks, necessary but not to be imitated without such necessity. I believe both affect how the lexer interprets code characters when it constructs literal value tokens to be fed to the parser.

Not quite -- the lexer passes the entire string literal uninterpreted to the parser (including quotes). It doesn't even need the 'b' or 'r' prefix to tell where the literal ends (though it does need the opening quote for that, and whether it's tripled). The code generation stage, however, looks at the prefix and interprets the contents of the literal differently based on the presence of 'b', and creates a different object depending on the presence of 'b'. (Or 'u' in Python 2.)

Collection-content displays are not, in general, constant and generally produce run-time code.

(?)

OrderedDict({'a':1', 'b':'2', 'c':'3'}]

...

How about ['a':'1', 'b':'2', 'c':'3']?

-100.

Guido van Rossum wrote:

On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedytjreedy@udel.edu wrote:

...

Collection-content displays are not, in general, constant and generally produce run-time code.

(?)

Somewhat expanded, I meant this:

Literals represent constants. They are sensibly interpreted into constants sometime before runtime, even if at a later stage than I thought.

Displays, in general, can contain variables and expressions that can only be evaluated at runtime. Therefore, the object they represent must, in general, be evaluated at runtime. (The pre-computation of tuples that only contain constants is an implementation-specific special case optimization.)

Code literals and code displays are, in this way among others, different beasts. Therefore, a device used for literals is not necessarily a good device for displays. The latter use needs more justification than the precedent of the former use.

The OP has not provided such justification for an admittedly ugly device.

-1 (which we agree on)

Terry Jan Reedy

Ron Adam wrote:

Ben Finney wrote:

...

Carl Johnson writes:

...

we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal.

What do you mean by “more explicit”? The existing set literal syntax is quite explicit.

I think Carl is thinking that it is more concise and easier to read.

Yes, that's part of it. Thank you. What I mean by "explicit" in this case is something like "harder to accidentally misparse in your mind." So for example if you see {f(i) for i in my_data} obviously it is unambiguously a set-comprehension, but if you aren't paying close enough attention you might mistakenly think it was a dict-comprehension. On the other hand, s{f(i) for i in my_data} more or less screams, "I am a set-comprehension!" On the other hand, it's ugly, and the BDFL doesn't like it. So, it's probably a dead idea now…

Terry Reedy wrote:

Literals represent constants. They are sensibly interpreted into constants sometime before runtime, even if at a later stage than I thought.

I'm not sure what you're getting at here. What about d = {} ? That's not immutable. Nor is l = [1, 2, 3]. Or by "constant" do you just mean something that will be the same at the *start* of every program, but it may or may not change before the program is over?

- - - -

I think ["a": 1, "b": 2] is an interesting syntax, and certainly more elegant than o{"a": 1, "b": 2} but I worry that it could be ambiguous. I can't think of any way to do it off the top of my head, but might there be some valid way of writing l[1:2] that could be ambiguous between the two? If nothing else, it would confuse newbies about what [:] means: slice or odict?

-- Carl

Carl Johnson wrote:

Ron Adam wrote:

...

Ben Finney wrote:

...

Carl Johnson writes:

...

we could introduce an empty set-literal and an odict-literal, and add a more explicit form to replace the existing set literal.

What do you mean by “more explicit”? The existing set literal syntax is quite explicit.

I think Carl is thinking that it is more concise and easier to read.

Yes, that's part of it. Thank you. What I mean by "explicit" in this case is something like "harder to accidentally misparse in your mind." So for example if you see {f(i) for i in my_data} obviously it is unambiguously a set-comprehension, but if you aren't paying close enough attention you might mistakenly think it was a dict-comprehension. On the other hand, s{f(i) for i in my_data} more or less screams, "I am a set-comprehension!" On the other hand, it's ugly, and the BDFL doesn't like it. So, it's probably a dead idea now…

Terry Reedy wrote:

...

Literals represent constants. They are sensibly interpreted into constants sometime before runtime, even if at a later stage than I thought.

I'm not sure what you're getting at here. What about d = {} ? That's not immutable. Nor is l = [1, 2, 3]. Or by "constant" do you just mean something that will be the same at the *start* of every program, but it may or may not change before the program is over?

---

I think ["a": 1, "b": 2] is an interesting syntax, and certainly more elegant than o{"a": 1, "b": 2} but I worry that it could be ambiguous. I can't think of any way to do it off the top of my head, but might there be some valid way of writing l[1:2] that could be ambiguous between the two? If nothing else, it would confuse newbies about what [:] means: slice or odict?

What about l[2]? Is [2] an index or a list?

Steven D'Aprano wrote:

On Wed, 17 Jun 2009 04:28:29 am Terry Reedy wrote:

...

...

...

When you read OrderedDict([('a', '1'),('b', '2'), ('c', '3')]),

OrderedDict({'a':1', 'b':'2', 'c':'3'}]

Creating an ordered dict from arbitrarily ordered input data surely ranks up there with one of the most pointless operations ever!

You know, this is such a simple, yet silly, mistake to make, I'd be almost tempted to disallow constructing an OrderedDict from regular dicts. If you want non-arbitrary ordering, you can't use a dict as input, and if you don't want arbitrary ordering, there's no point in using an ordered dict!

As far as I can see, there is no use-case for OrderedDict(dict) other than to generate confused newbies.

...

...

How about ['a':'1', 'b':'2', 'c':'3']?

Nice Idea!

I hope you're being sarcastic.

If hard-coded ordered dicts are common enough then having syntactic sugar for them would be a good idea: ['a':'1', 'b':'2', 'c':'3'] is both shorter and clearer than OrderedDict([('a', '1'),('b', '2'), ('c', '3')]). I doesn't feel that unPythonic to me.

But ordered dicts tend to be built one item at a time while iterating through some data whose values aren't known until runtime, so I doubt that ordered dict literals would be common enough anyway to warrant addition.

Guido van Rossum <guido@...> writes:

On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedy<tjreedy@...> wrote:

...

I consider b"" and r"" to be hacks, necessary but not to be imitated without such necessity. I believe both affect how the lexer interprets code characters when it constructs literal value tokens to be fed to the parser.

Not quite -- the lexer passes the entire string literal uninterpreted to the parser (including quotes). It doesn't even need the 'b' or 'r' prefix to tell where the literal ends (though it does need the opening quote for that, and whether it's tripled). The code generation stage, however, looks at the prefix and interprets the contents of the literal differently based on the presence of 'b', and creates a different object depending on the presence of 'b'. (Or 'u' in Python 2.)

<nitpicking> Technically, string decoding is done during the building of the AST not code generation. See parsestrplus in ast.c if you want to know all the gory details. </nitpicking>

Regards, Benjamin

Steven D'Aprano wrote:

As far as I can see, there is no use-case for OrderedDict(dict) other than to generate confused newbies.

It's possible that you don't care about the order of the initial items, but want to preserve the ordering of items added later.

Not sure how *likely* a requirement this is, though...

On Wed, Jun 17, 2009, Ben Finney wrote:

Guido van Rossum guido@python.org writes:

...

On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedytjreedy@udel.edu wrote:

...

OrderedDict({'a':1', 'b':'2', 'c':'3'}]

...

How about ['a':'1', 'b':'2', 'c':'3']?

-100.

(Hey! I though the valid range of votes was -1 through +1, I didn't know we were giving the BDFL more than one vote! :-)

Guido can vote; he can also Pronounce. -100 is a shorthand idiom for "veto".

(I know you were joking, but I figure there are probably people reading this who are not familiar with the Python development process or Guido's role in it.)

Aahz writes:

On Wed, Jun 17, 2009, Ben Finney wrote:

...

Guido van Rossum guido@python.org writes:

...

...

-100.

(Hey! I though the valid range of votes was -1 through +1, I didn't know we were giving the BDFL more than one vote! :-)

Guido can vote; he can also Pronounce. -100 is a shorthand idiom for "veto".

Erm, shorthand? But len("-100") == len("veto")? <wink>

I actually read that differently (though I don't pretend to be capable of channeling anybody). When I see a "-100" from Guido (and to nearly the same extent, from any 'bot---do bots express emotion this way?--- or the FLUFL), I make a note that "this kind of proposal is not merely unacceptable, it's in bad taste." Then I try to figure out why....

...and since the -100 is from Guido, you can basically forget it. It won't happen.

On Wed, Jun 17, 2009 at 8:58 PM, Greg Ewinggreg.ewing@canterbury.ac.nz wrote:

Aahz wrote:

...

Guido can vote; he can also Pronounce.  -100 is a shorthand idiom for "veto".

(I know you were joking, but I figure there are probably people reading this who are not familiar with the Python development process or Guido's role in it.)

To further elucidate for those people, the +/-n numbers are not really votes -- nobody is adding them up and making a decision based solely on the total. They're just an expression of opinion, so you sometimes see things like -100 or -1000 to mean "I *really* don't like this".

-- Greg _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

MRAB <python@...> writes:

Gerald Britton wrote:

...

...and since the -100 is from Guido, you can basically forget it. It won't happen.

Unless he gets hit by a bus, or a drive-by shooting by Larry Wall.

If people had to use Perl 6 when shooting each other, criminality problems would disappear instantly.

Regards

Antoine.