Possible method of distinguishing between set-literals, dict-literals, and odict-literals
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? -- Carl Johnson
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
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 Finney<ben+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
-- Gerald Britton
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. 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. Ron
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)
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?
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. Collection-content displays are not, in general, constant and generally produce run-time code.
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 Reedy<tjreedy@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 (home page: http://www.python.org/~guido/)
Le Tue, 16 Jun 2009 18:46:21 +0100, MRAB <python@mrabarnett.plus.com> s'exprima ainsi:
How about ['a':'1', 'b':'2', 'c':'3']? (for ordered dict literal)
I really find this sensible. We have then: * [a, b, c] & [k1:v1, k2:v2, k3:v3] for ordered containers * {a, b, c} & {k1:v1, k2:v2, k3:v3} for unordered ones +1.0 for me Update: confusion of 1-item ordered dict with slice? Or just the same as confusion of 1-item list with index? (Note: have always found that [] and [:] for index and slice was somewhat wrong). Denis ------ la vita e estrany
Guido van Rossum wrote:
On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedy<tjreedy@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
spir wrote:
Le Tue, 16 Jun 2009 18:46:21 +0100, MRAB <python@mrabarnett.plus.com> s'exprima ainsi:
How about ['a':'1', 'b':'2', 'c':'3']? (for ordered dict literal)
I really find this sensible. We have then: * [a, b, c] & [k1:v1, k2:v2, k3:v3] for ordered containers * {a, b, c} & {k1:v1, k2:v2, k3:v3} for unordered ones
+1.0 for me
Update: confusion of 1-item ordered dict with slice? Or just the same as confusion of 1-item list with index? (Note: have always found that [] and [:] for index and slice was somewhat wrong).
Can you confuse a 1-item list with an index? No, because the syntax/grammar disambiguates them. Is that also the case with a 1-item ordered dict vs a slice? In Python 2.6, [0 : 1] (== slice(0, 1)) raises SyntaxError. Does that also occur in Python 3.x?
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?
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. -- Steven D'Aprano
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.
MRAB <python@mrabarnett.plus.com> writes:
[for a literal OrderedDict,] How about ['a':'1', 'b':'2', 'c':'3']?
+1. That's quite good, and has symmetry with existing syntax:: {'fred', 'barney', 4.75} # unordered set ['fred', 'barney', 4.75] # ordered list {'foo': 10.2, 'bar': 8.19} # unordered dict ['foo': 10.2, 'bar': 8.19] # ordered dict That looks good to me.
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)
-0. Unlike syntax for creating and populating an instance, I actually don't think we need to worry about having specific syntax for empty. Compared to a non-empty container, it's quite a lower burden to simply have an explicit call to the type constructor to create an empty container. -- \ “Probably the toughest time in anyone's life is when you have | `\ to murder a loved one because they're the devil.” —Emo Philips | _o__) | Ben Finney
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
Guido van Rossum <guido@python.org> writes:
On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedy<tjreedy@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! :-) Can you summarise what you dislike about the above syntax suggestion for ordered dict literal? -- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
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... -- Greg
Personally, if I had a time machine I would pick a syntax like set{...} over set([...]) but I don't have a time machine and even if I did I don't think I'd use it for that. The difference is that the former is special syntax, while the latter isn't. No matter what I do to the the varible r, r"string" is still a string, while set([...]) can be perverted. However, given what we've got I can't really say that ([ instead of { is that big a deal. --- Bruce On Tue, Jun 16, 2009 at 5:25 PM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:
Guido van Rossum <guido@python.org> writes:
On Tue, Jun 16, 2009 at 11:24 AM, Terry Reedy<tjreedy@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! :-)
Can you summarise what you dislike about the above syntax suggestion for ordered dict literal?
-- \ “If the desire to kill and the opportunity to kill came always | `\ together, who would escape hanging?” —Mark Twain, _Following | _o__) the Equator_ | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
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 Reedy<tjreedy@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 (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "Many customs in this life persist because they ease friction and promote productivity as a result of universal agreement, and whether they are precisely the optimal choices is much less important." --Henry Spencer
Bruce Leban wrote:
Personally, if I had a time machine I would pick a syntax like set{...} over set([...]) but I don't have a time machine and even if I did I don't think I'd use it for that. The difference is that the former is special syntax, while the latter isn't. No matter what I do to the the varible r, r"string" is still a string, while set([...]) can be perverted.
However, given what we've got I can't really say that ([ instead of { is that big a deal.
[snip] You can have any iterable between the (...); it's just that the iterable happens to be a list literal.
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....
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
...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 Ewing<greg.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
-- Gerald Britton
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. :-)
On Wed, Jun 17, 2009 at 8:58 PM, Greg Ewing<greg.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.
participants (16)
-
Aahz -
Antoine Pitrou -
Ben Finney -
Benjamin Peterson -
Bruce Leban -
Carl Johnson -
Gerald Britton -
Greg Ewing -
Guido van Rossum -
MRAB -
Ron Adam -
spir -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy -
Vitor Bosshard