Re: Comparison Style
On 4/27/2013 5:03 PM, Roy Smith wrote: In article , Chris Angelico wrote: If you switch the order of operands in that, the compiler won't help you. Plus it "reads" wrong. So the convention is still variable==constant. I just found a nice example of putting the constant first. I've just done a whole bunch of ugly math to find some slice limits. To make sure they're sane, I'm writing: assert 5 <= i < j < original_song_count I can't think of any way to write that which would be as clean and easy to read. Chained comparisons like this are standard math notation, which is why Python 'does the right thing' with them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
In article , Chris Angelico wrote: > If you switch the order of operands in that, the compiler won't help > you. Plus it "reads" wrong. So the convention is still > variable==constant. I just found a nice example of putting the constant first. I've just done a whole bunch of ugly math to find some slice limits. To make sure they're sane, I'm writing: assert 5 <= i < j < original_song_count I can't think of any way to write that which would be as clean and easy to read. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On 25/04/2013 21:35, Steve Simmons wrote: The Ying Tong song - a classic of its time. But eminently suited to the chorally challenged. Released on a classic EP with Major Dennis Bloodnok's Rock and Roll Call Rumba, I'm walking Backwards for Christmas and Bluebottle Blues. Bravado, bravado. What a voice! (What a bank balance!) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On 04/25/2013 10:48 PM, Chris Angelico wrote:
Also, this protection helps only when the "constant"
is actually something the compiler knows is a constant - it doesn't
work in a search function, for instance:
char *strchr(char *string, char findme) {
while (*string) {
if (*string==findme) return string;
++string;
}
return 0;
}
Sure, but if I were coding in C again, I'd have made that function signature
char *strchr(char *string, const char findme) {
or maybe
char *strchr(const char *string, const char findme) {
If you switch the order of operands in that, the compiler won't help
you.
Yes, it would.
Plus it "reads" wrong. So the convention is still
variable==constant.
In my case, after having it drilled in that you're "supposed" to put the
constant first, I realized that I never had any problem with using =,
because as soon as I questioned the order, I just double-checked that I
was using ==. At that point, there was no longer any benefit to making
the order backwards.
--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On Fri, Apr 26, 2013 at 12:37 PM, Dennis Lee Bieber
wrote:
> On Thu, 25 Apr 2013 15:57:49 +1000, Chris Angelico
> declaimed the following in gmane.comp.python.general:
>> It's conventional to compare variables to constants, not constants to
>> variables (even in C where there's the possibility of mucking up the
>> operator, most people still compare variables to constants).
>
> The main reason for /literal/ first is to trap C/C++ assignment as
> expression.
>
> if (x = 5)
>
> ends up assigning x the value 5 and THEN, since 5 is "true" executing
> the "then" part.
>
> if (5 = x)
>
> OTOH is a compiler error.
>
Aware of this. My point is that, even though there's a good reason for
putting the constant first, it's still FAR more common to put the
variable first. Also, this protection helps only when the "constant"
is actually something the compiler knows is a constant - it doesn't
work in a search function, for instance:
char *strchr(char *string, char findme) {
while (*string) {
if (*string==findme) return string;
++string;
}
return 0;
}
If you switch the order of operands in that, the compiler won't help
you. Plus it "reads" wrong. So the convention is still
variable==constant.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
llanitedave wrote: >On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote: >> Chris Angelico wrote: >> >> >> >> With the sort of thinking you're demonstrating here, you >> >> should consider a job working with Spike Milligna (the well known >typing error). >> >> >> >> Errr , I think you'll find that he's joined the choir invisibule. >Mind you, he did say he was ill! >> >> >> >> Sent from a Galaxy far far away > > >Did you ever hear him sing? He's better off in the choir inaudible. > >As am I... >-- >http://mail.python.org/mailman/listinfo/python-list The Ying Tong song - a classic of its time. But eminently suited to the chorally challenged. Sent from a Galaxy far far away-- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On 2013-04-25, llanitedave wrote: >> Errr , I think you'll find that he's joined the choir >> invisibule. Mind you, he did say he was ill! >> >> Sent from a Galaxy far far away > > Did you ever hear him sing? He's better off in the choir > inaudible. Well I've never heard either one. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote: > Chris Angelico wrote: > > > > With the sort of thinking you're demonstrating here, you > > should consider a job working with Spike Milligna (the well known typing > error). > > > > Errr , I think you'll find that he's joined the choir invisibule. Mind you, > he did say he was ill! > > > > Sent from a Galaxy far far away Did you ever hear him sing? He's better off in the choir inaudible. As am I... -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
Chris Angelico wrote: With the sort of thinking you're demonstrating here, you should consider a job working with Spike Milligna (the well known typing error). Errr , I think you'll find that he's joined the choir invisibule. Mind you, he did say he was ill! Sent from a Galaxy far far away -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On Fri, Apr 26, 2013 at 12:19 AM, llanitedave wrote: > On Wednesday, April 24, 2013 10:57:49 PM UTC-7, Chris Angelico wrote: >> I thought programming WAS a hobby? >> > > I meant a safer, easier, and more mainstream hobby, like base jumping or > motorcycle aerobatics or something. Good point. With the sort of thinking you're demonstrating here, you should consider a job working with Spike Milligna (the well-known typing error). I believe there ought to be an office cubicle available for you in one of the excellent organizations devoted to Milliganesque thinkers and computer programmers - the walls are nicely padded... ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On Wednesday, April 24, 2013 10:57:49 PM UTC-7, Chris Angelico wrote: > On Thu, Apr 25, 2013 at 3:49 PM, llanitedave wrote: > > > Given that > > > > > > s = some static value > > > i = a value incremented during a loop > > > > > > I'm used to comparing them as > > > > > > if i == s: > > > # some code > > > > > > But for some unknown reason I did a switch > > > > > > if s == i: > > > # same code > > > > > > It didn't seem to make any difference at first glance, so I just got to > > wondering -- > > > > It won't make any difference in any sort of sane code. If there's any > > situation in which == is not reflexive, something seriously nasty is > > going on. > > > > > Is there a standard for comparison order? Is there any kind of performance > > difference? Is there even a tradition for one or the other? Are there any > > gotchas? > > > > It's conventional to compare variables to constants, not constants to > > variables (even in C where there's the possibility of mucking up the > > operator, most people still compare variables to constants). I'd > > normally use "i == s" there, treating s as a constant for the purpose > > of the loop. Unless you're deliberately being poetical, language such > > as "Three is the number thou shalt count" is distinctly abnormal, so > > saying "if (5 == i)" is equally awkward. It's nothing major; mostly > > it's like the algebraic convention of putting the more-known elements > > earlier in a term (eg 2πix - 2 is known, 3.14159 is mostly known, > > i is imaginary but at least it's constant, and x is unknown). > > Thanks, Chris. That's kind of along the lines of what I was thinking. Visually, the code just looked wrong, and I figure if for no other reasons than readability it's preferable in the traditional way. It's nice to know, though, that the next time dyslexia strikes it's not necessarily a horrible thing. > > > Do I need to get a hobby? > > > > I thought programming WAS a hobby? > I meant a safer, easier, and more mainstream hobby, like base jumping or motorcycle aerobatics or something. -- http://mail.python.org/mailman/listinfo/python-list
Re: Comparison Style
On Thu, Apr 25, 2013 at 3:49 PM, llanitedave wrote: > Given that > > s = some static value > i = a value incremented during a loop > > I'm used to comparing them as > > if i == s: > # some code > > But for some unknown reason I did a switch > > if s == i: > # same code > > It didn't seem to make any difference at first glance, so I just got to > wondering -- It won't make any difference in any sort of sane code. If there's any situation in which == is not reflexive, something seriously nasty is going on. > Is there a standard for comparison order? Is there any kind of performance > difference? Is there even a tradition for one or the other? Are there any > gotchas? It's conventional to compare variables to constants, not constants to variables (even in C where there's the possibility of mucking up the operator, most people still compare variables to constants). I'd normally use "i == s" there, treating s as a constant for the purpose of the loop. Unless you're deliberately being poetical, language such as "Three is the number thou shalt count" is distinctly abnormal, so saying "if (5 == i)" is equally awkward. It's nothing major; mostly it's like the algebraic convention of putting the more-known elements earlier in a term (eg 2πix - 2 is known, 3.14159 is mostly known, i is imaginary but at least it's constant, and x is unknown). > Do I need to get a hobby? I thought programming WAS a hobby? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Comparison Style
Given that s = some static value i = a value incremented during a loop I'm used to comparing them as if i == s: # some code But for some unknown reason I did a switch if s == i: # same code It didn't seem to make any difference at first glance, so I just got to wondering -- Is there a standard for comparison order? Is there any kind of performance difference? Is there even a tradition for one or the other? Are there any gotchas? Do I need to get a hobby? -- http://mail.python.org/mailman/listinfo/python-list
