Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #44322 > unrolled thread

Comparison Style

Back to article view | Back to comp.lang.python

Contents

  Comparison Style llanitedave <llanitedave@veawb.coop> - 2013-04-24 22:49 -0700
    Re: Comparison Style Chris Angelico <rosuav@gmail.com> - 2013-04-25 15:57 +1000
      Re: Comparison Style llanitedave <llanitedave@veawb.coop> - 2013-04-25 07:19 -0700
        Re: Comparison Style Chris Angelico <rosuav@gmail.com> - 2013-04-26 02:25 +1000
        Re: Comparison Style Steve Simmons <square.steve@gmail.com> - 2013-04-25 19:31 +0100
          Re: Comparison Style llanitedave <llanitedave@veawb.coop> - 2013-04-25 13:13 -0700
            Re: Comparison Style Neil Cerutti <neilc@norwich.edu> - 2013-04-25 20:15 +0000
            Re: Comparison Style Steve Simmons <square.steve@gmail.com> - 2013-04-25 21:35 +0100
            Re: Comparison Style Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-26 10:02 +0100
    Re: Comparison Style Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-25 22:37 -0400
    Re: Comparison Style Chris Angelico <rosuav@gmail.com> - 2013-04-26 12:48 +1000
      Re: Comparison Style Roy Smith <roy@panix.com> - 2013-04-27 17:03 -0400
        Re: Comparison Style Terry Jan Reedy <tjreedy@udel.edu> - 2013-04-27 17:40 -0400
    Re: Comparison Style Dave Angel <davea@davea.name> - 2013-04-25 23:43 -0400

#44322 — 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?

[toc] | [next] | [standalone]

#44323

On Thu, Apr 25, 2013 at 3:49 PM, llanitedave <llanitedave@veawb.coop> 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

[toc] | [prev] | [next] | [standalone]

#44343

On Wednesday, April 24, 2013 10:57:49 PM UTC-7, Chris Angelico wrote:
> On Thu, Apr 25, 2013 at 3:49 PM, llanitedave <llanitedave@veawb.coop> 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.

[toc] | [prev] | [next] | [standalone]

#44354

On Fri, Apr 26, 2013 at 12:19 AM, llanitedave <llanitedave@veawb.coop> 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

[toc] | [prev] | [next] | [standalone]

#44357

Chris Angelico <rosuav@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#44359

On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote:
> Chris Angelico <rosuav@gmail.com> 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...

[toc] | [prev] | [next] | [standalone]

#44360

On 2013-04-25, llanitedave <llanitedave@veawb.coop> 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

[toc] | [prev] | [next] | [standalone]

#44361

[Multipart message — attachments visible in raw view] — view raw

llanitedave <llanitedave@veawb.coop> wrote:

>On Thursday, April 25, 2013 11:31:04 AM UTC-7, Steve Simmons wrote:
>> Chris Angelico <rosuav@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#44398

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

[toc] | [prev] | [next] | [standalone]

#44376

On Thu, 25 Apr 2013 15:57:49 +1000, Chris Angelico <rosuav@gmail.com>
declaimed the following in gmane.comp.python.general:

> On Thu, Apr 25, 2013 at 3:49 PM, llanitedave <llanitedave@veawb.coop> 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).
>

	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.

	But since Python doesn't allow assignment/binding as an expression,
either would be flagged an error.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#44379

On Fri, Apr 26, 2013 at 12:37 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Thu, 25 Apr 2013 15:57:49 +1000, Chris Angelico <rosuav@gmail.com>
> 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

[toc] | [prev] | [next] | [standalone]

#44454

In article <mailman.1077.1366944517.3114.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#44455

On 4/27/2013 5:03 PM, Roy Smith wrote:
> In article <mailman.1077.1366944517.3114.python-list@python.org>,
>   Chris Angelico <rosuav@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#44381

On 04/25/2013 10:48 PM, Chris Angelico wrote:

     <SNIP>

> 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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web