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

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

First python program, syntax error in while loop

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

Contents

  First python program, syntax error in while loop ryankoch38@gmail.com - 2013-05-03 10:18 -0700
    Re: First python program, syntax error in while loop John Gordon <gordon@panix.com> - 2013-05-03 17:27 +0000
    Re: First python program, syntax error in while loop Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2013-05-03 19:26 +0200
      Re: First python program, syntax error in while loop John Gordon <gordon@panix.com> - 2013-05-03 17:37 +0000
    Re: First python program, syntax error in while loop MRAB <python@mrabarnett.plus.com> - 2013-05-03 18:36 +0100
    Re: First python program, syntax error in while loop Zachary Ware <zachary.ware+pylist@gmail.com> - 2013-05-03 12:37 -0500
    Re: First python program, syntax error in while loop ryankoch38@gmail.com - 2013-05-03 10:57 -0700
      Re: First python program, syntax error in while loop John Gordon <gordon@panix.com> - 2013-05-03 18:21 +0000
        Re: First python program, syntax error in while loop ryankoch38@gmail.com - 2013-05-03 11:34 -0700
    Re: First python program, syntax error in while loop ryankoch38@gmail.com - 2013-05-03 12:52 -0700
      Re: First python program, syntax error in while loop John Gordon <gordon@panix.com> - 2013-05-03 20:04 +0000
    Re: First python program, syntax error in while loop ryankoch38@gmail.com - 2013-05-03 13:15 -0700
      Re: First python program, syntax error in while loop Neil Cerutti <neilc@norwich.edu> - 2013-05-03 20:30 +0000
        Re: First python program, syntax error in while loop John Gordon <gordon@panix.com> - 2013-05-03 20:38 +0000
          Re: First python program, syntax error in while loop Neil Cerutti <neilc@norwich.edu> - 2013-05-06 12:06 +0000
            Re: First python program, syntax error in while loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-05-06 13:37 +0100
              Re: First python program, syntax error in while loop Neil Cerutti <neilc@norwich.edu> - 2013-05-06 13:07 +0000
              Re: First python program, syntax error in while loop Roy Smith <roy@panix.com> - 2013-05-06 09:08 -0400
                Re: First python program, syntax error in while loop rusi <rustompmody@gmail.com> - 2013-05-06 06:36 -0700
                Re: First python program, syntax error in while loop Chris Angelico <rosuav@gmail.com> - 2013-05-06 23:37 +1000
                  Re: First python program, syntax error in while loop roy@panix.com (Roy Smith) - 2013-05-06 11:31 -0400
                    Re: First python program, syntax error in while loop Terry Jan Reedy <tjreedy@udel.edu> - 2013-05-06 16:11 -0400
                    Re: First python program, syntax error in while loop Chris Angelico <rosuav@gmail.com> - 2013-05-07 07:50 +1000
                Re: First python program, syntax error in while loop Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-05-06 20:16 -0400
              Re: First python program, syntax error in while loop alex23 <wuwei23@gmail.com> - 2013-05-06 17:17 -0700
                Re: First python program, syntax error in while loop Roy Smith <roy@panix.com> - 2013-05-06 20:18 -0400
                Re: First python program, syntax error in while loop Dan Sommers <dan@tombstonezero.net> - 2013-05-07 05:03 +0000
                Re: First python program, syntax error in while loop Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-05-07 07:10 +0100
                Re: First python program, syntax error in while loop Chris Angelico <rosuav@gmail.com> - 2013-05-07 19:19 +1000

Page 2 of 2 — ← Prev page 1 [2]

#44832

In article <mailman.1361.1367847484.3114.python-list@python.org>,
Chris Angelico  <rosuav@gmail.com> wrote:
>On Mon, May 6, 2013 at 11:08 PM, Roy Smith <roy@panix.com> wrote:
>> On the other hand, I've long since given up trying to remember operator
>> precedence in various languages.  If I ever have even the slightest
>> doubt, I just go ahead and put in the extra parens.
>
>If I ever have even the slightest doubt, I just go ahead and type
>"<language> operator precedence" into a web search and check it :)

Well, that solves the problem once, and it solves it for me.  I figure
if I'm not 100% sure, then maybe other people aren't 100% sure either,
and my adding the extra parens helps them too.

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

#44847

On 5/6/2013 11:31 AM, Roy Smith wrote:
> In article <mailman.1361.1367847484.3114.python-list@python.org>,
> Chris Angelico  <rosuav@gmail.com> wrote:
>> On Mon, May 6, 2013 at 11:08 PM, Roy Smith <roy@panix.com> wrote:
>>> On the other hand, I've long since given up trying to remember operator
>>> precedence in various languages.  If I ever have even the slightest
>>> doubt, I just go ahead and put in the extra parens.
>>
>> If I ever have even the slightest doubt, I just go ahead and type
>> "<language> operator precedence" into a web search and check it :)
>
> Well, that solves the problem once, and it solves it for me.  I figure
> if I'm not 100% sure, then maybe other people aren't 100% sure either,
> and my adding the extra parens helps them too.

If you keep the Python docs handy, on or off line, the Language manual 
Expressions chapter ends with this single page (but better formatted as 
a table than here). But I sometimes add parens for quickness or readability.

6.15. Operator precedence
The following table summarizes the operator precedences in Python, from 
lowest precedence (least binding) to highest precedence (most binding). 
Operators in the same box have the same precedence. Unless the syntax is 
explicitly given, operators are binary. Operators in the same box group 
left to right (except for comparisons, including tests, which all have 
the same precedence and chain from left to right — see section 
Comparisons — and exponentiation, which groups from right to left).

Operator Description
lambda Lambda expression
if – else Conditional expression
or Boolean OR
and Boolean AND
not x Boolean NOT
in, not in, is, is not, <, <=, >, >=, !=, == Comparisons, including 
membership tests and identity tests,
| Bitwise OR
^ Bitwise XOR
& Bitwise AND
<<, >> Shifts
+, - Addition and subtraction
*, /, //, % Multiplication, division, remainder [5]
+x, -x, ~x Positive, negative, bitwise NOT
** Exponentiation [6]
x[index], x[index:index], x(arguments...), x.attribute Subscription, 
slicing, call, attribute reference
(expressions...), [expressions...], {key: value...}, {expressions...} 
Binding or tuple display, list display, dictionary display, set display

Footnotes

[1] While abs(x%y) < abs(y) is true mathematically, for floats it may 
not be true numerically due to roundoff. For example, and assuming a 
platform on which a Python float is an IEEE 754 double-precision number, 
in order that -1e-100 % 1e100 have the same sign as 1e100, the computed 
result is -1e-100 + 1e100, which is numerically exactly equal to 1e100. 
The function math.fmod() returns a result whose sign matches the sign of 
the first argument instead, and so returns -1e-100 in this case. Which 
approach is more appropriate depends on the application.
[2] If x is very close to an exact integer multiple of y, it’s possible 
for x//y to be one larger than (x-x%y)//y due to rounding. In such 
cases, Python returns the latter result, in order to preserve that 
divmod(x,y)[0] * y + x % y be very close to x.
[3] While comparisons between strings make sense at the byte level, they 
may be counter-intuitive to users. For example, the strings "\u00C7" and 
"\u0327\u0043" compare differently, even though they both represent the 
same unicode character (LATIN CAPITAL LETTER C WITH CEDILLA). To compare 
strings in a human recognizable way, compare using unicodedata.normalize().
[4] Due to automatic garbage-collection, free lists, and the dynamic 
nature of descriptors, you may notice seemingly unusual behaviour in 
certain uses of the is operator, like those involving comparisons 
between instance methods, or constants. Check their documentation for 
more info.
[5] The % operator is also used for string formatting; the same 
precedence applies.
[6] The power operator ** binds less tightly than an arithmetic or 
bitwise unary operator on its right, that is, 2**-1 is 0.5.

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

#44855

On Tue, May 7, 2013 at 6:11 AM, Terry Jan Reedy <tjreedy@udel.edu> wrote:
> On 5/6/2013 11:31 AM, Roy Smith wrote:
>>
>> In article <mailman.1361.1367847484.3114.python-list@python.org>,
>> Chris Angelico  <rosuav@gmail.com> wrote:
>>> If I ever have even the slightest doubt, I just go ahead and type
>>> "<language> operator precedence" into a web search and check it :)
>>
>>
>> Well, that solves the problem once, and it solves it for me.  I figure
>> if I'm not 100% sure, then maybe other people aren't 100% sure either,
>> and my adding the extra parens helps them too.
>
>
> If you keep the Python docs handy, on or off line, the Language manual
> Expressions chapter ends with this single page (but better formatted as a
> table than here). But I sometimes add parens for quickness or readability.
>
> or Boolean OR
> and Boolean AND

Actually, this is one exception. I tend to parenthesize any case where
there's a complex set of conditions and mixed AND and OR operations.
Part of the reason for this is that any expression that can be
affected by the precedence of and and or will most likely be fairly
long and/or complex anyway, so a few extra parens won't hurt.

ChrisA

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

#44865

On Mon, 06 May 2013 09:08:44 -0400, Roy Smith <roy@panix.com> declaimed
the following in gmane.comp.python.general:

> 
> In this case, however, I have no problem with the extra parens.  Look at 
> these two statements:
> 
> >> while (number != guess) and (tries < 5):
> >> while number != guess and tries < 5:
> 
> They have the same meaning.  To correctly interpret the second one, you 
> need to know that != and < bind tighter than "and". One could say that 
> you should know that, and maybe you would be right.
>
	If there were a chance of confusion, I'd probably have written it

	while (number != guess
			and tries < 5) :

(yes, a deliberate line break, not a news reader line wrap)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#44864

On May 6, 10:37 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
> One of these days I'll work out why some people insist on using
> superfluous parentheses in Python code.  Could it be that they enjoy
> exercising their fingers by reaching for the shift key in conjunction
> with the 9 or 0 key?

One of these days I'll work out why some programmers consider typing
to be "effort".

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

#44866

In article 
<b00aecc2-149d-4ba8-a096-267dc881d0a1@n5g2000pbg.googlegroups.com>,
 alex23 <wuwei23@gmail.com> wrote:

> On May 6, 10:37 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
> > One of these days I'll work out why some people insist on using
> > superfluous parentheses in Python code.  Could it be that they enjoy
> > exercising their fingers by reaching for the shift key in conjunction
> > with the 9 or 0 key?
> 
> One of these days I'll work out why some programmers consider typing
> to be "effort".

RSI.

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

#44872

On Mon, 06 May 2013 17:17:01 -0700, alex23 wrote:

> One of these days I'll work out why some programmers consider typing to
> be "effort".

An ironic comment from someone who goes by the moniker wu wei!  ;-)

The effort, of course, comes in determining what to type, and often how to
type less.

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

#44874

On 07/05/2013 01:17, alex23 wrote:
> On May 6, 10:37 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
>> One of these days I'll work out why some people insist on using
>> superfluous parentheses in Python code.  Could it be that they enjoy
>> exercising their fingers by reaching for the shift key in conjunction
>> with the 9 or 0 key?
>
> One of these days I'll work out why some programmers consider typing
> to be "effort".
>

I think it's very important to consider this aspect.  E.g. any one using 
dynamically typed languages has to put in more effort as they should be 
typing up their test code, whereas people using statically typed 
languages can simply head down to the pub once their code has compiled.

-- 
If you're using GoogleCrap™ please read this 
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence

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

#44877

On Tue, May 7, 2013 at 4:10 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 07/05/2013 01:17, alex23 wrote:
>>
>> On May 6, 10:37 pm, Mark Lawrence <breamore...@yahoo.co.uk> wrote:
>>>
>>> One of these days I'll work out why some people insist on using
>>> superfluous parentheses in Python code.  Could it be that they enjoy
>>> exercising their fingers by reaching for the shift key in conjunction
>>> with the 9 or 0 key?
>>
>>
>> One of these days I'll work out why some programmers consider typing
>> to be "effort".
>>
>
> I think it's very important to consider this aspect.  E.g. any one using
> dynamically typed languages has to put in more effort as they should be
> typing up their test code, whereas people using statically typed languages
> can simply head down to the pub once their code has compiled.

And those who are porting other people's code to a new platform have
weeks of work just to get ./configure to run, but after that it's
smooth...

Everything is variable.

ChrisA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web