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

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

Operator precedence problem

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

Contents

  Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-04 23:53 -0700
    Re: Operator precedence problem Peter Otten <__peter__@web.de> - 2016-06-05 09:35 +0200
      Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 08:05 -0700
        Re: Operator precedence problem Uri Even-Chen <uri@speedy.net> - 2016-06-05 19:05 +0300
          Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 20:24 -0700
          Re: Operator precedence problem Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-05 22:46 -0700
            Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-06 09:57 -0400
              Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 17:22 +0300
                Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-06 10:35 -0400
                  Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 17:55 +0300
                Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 15:03 +0000
                  Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 18:22 +0300
                    Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 15:27 +0000
                      Re: Operator precedence problem Chris Angelico <rosuav@gmail.com> - 2016-06-07 01:57 +1000
                        Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 16:05 +0000
                          Re: Operator precedence problem Chris Angelico <rosuav@gmail.com> - 2016-06-07 02:21 +1000
                            Re: Operator precedence problem Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-06-06 17:02 +0000
                      Re: Operator precedence problem Grant Edwards <grant.b.edwards@gmail.com> - 2016-06-06 16:51 +0000
                Re: Operator precedence problem Peter Otten <__peter__@web.de> - 2016-06-06 18:38 +0200
              Re: Operator precedence problem Steven D'Aprano <steve@pearwood.info> - 2016-06-07 03:07 +1000
                Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-06 14:44 -0400
                  Re: Operator precedence problem Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 21:49 +0300
                Re: Operator precedence problem MRAB <python@mrabarnett.plus.com> - 2016-06-06 20:17 +0100
                  Re: Operator precedence problem Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 11:27 +1200
              Re: Operator precedence problem Rustom Mody <rustompmody@gmail.com> - 2016-06-06 10:14 -0700
                Re: Operator precedence problem Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-06 21:09 +0100
        Re: Operator precedence problem Michael Torrie <torriem@gmail.com> - 2016-06-05 17:47 -0600
          Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 20:23 -0700
    Re: Operator precedence problem Chris Angelico <rosuav@gmail.com> - 2016-06-06 02:24 +1000
      Re: Operator precedence problem Peter Pearson <pkpearson@nowhere.invalid> - 2016-06-06 16:58 +0000
        Re: Operator precedence problem Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 11:21 +1200
    Re: Operator precedence problem Random832 <random832@fastmail.com> - 2016-06-05 13:19 -0400
      Re: Operator precedence problem ICT Ezy <ictezy@gmail.com> - 2016-06-05 20:23 -0700
    Re: Operator precedence problem Gary Herron <gherron@digipen.edu> - 2016-06-05 00:04 -0700

Page 1 of 2  [1] 2  Next page →

#109498 — Operator precedence problem

>>> 2 ** 3 ** 2 
Answer is 512
Why not 64?
Order is right-left or left-right?

[toc] | [next] | [standalone]

#109502

ICT Ezy wrote:

>>>> 2 ** 3 ** 2
> Answer is 512
> Why not 64?
> Order is right-left or left-right?

** is a special case:

"""
The power operator ** binds less tightly than an arithmetic or bitwise unary 
operator on its right, that is, 2**-1 is 0.5.
"""
https://docs.python.org/3.5/reference/expressions.html#id21

Here's a little demo:

$ cat arithdemo.py
class A:
    def __init__(self, value):
        self.value = str(value)
    def __add__(self, other):
        return self._op(other, "+")
    def __pow__(self, other):
        return self._op(other, "**")
    def __repr__(self):
        return self.value
    def _op(self, other, op):
        return A("({} {} {})".format(self.value, op, other.value))
$ python3 -i arithdemo.py 
>>> A(1) + A(2) + A(3)
((1 + 2) + 3)
>>> A(1) ** A(2) ** A(3)
(1 ** (2 ** 3))

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

#109512

On Sunday, June 5, 2016 at 1:06:21 PM UTC+5:30, Peter Otten wrote:
> ICT Ezy wrote:
> 
> >>>> 2 ** 3 ** 2
> > Answer is 512
> > Why not 64?
> > Order is right-left or left-right?
> 
> ** is a special case:
> 
> """
> The power operator ** binds less tightly than an arithmetic or bitwise unary 
> operator on its right, that is, 2**-1 is 0.5.
> """
> https://docs.python.org/3.5/reference/expressions.html#id21
> 
> Here's a little demo:
> 
> $ cat arithdemo.py
> class A:
>     def __init__(self, value):
>         self.value = str(value)
>     def __add__(self, other):
>         return self._op(other, "+")
>     def __pow__(self, other):
>         return self._op(other, "**")
>     def __repr__(self):
>         return self.value
>     def _op(self, other, op):
>         return A("({} {} {})".format(self.value, op, other.value))
> $ python3 -i arithdemo.py 
> >>> A(1) + A(2) + A(3)
> ((1 + 2) + 3)
> >>> A(1) ** A(2) ** A(3)
> (1 ** (2 ** 3))

Thank you very much for your explanation 

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

#109516

My suggestion: Never write expressions, such as  2 ** 3 ** 2 or even 2 * 4
+ 5, without parentheses. Always add parentheses - 2 ** (3 ** 2) (or (2 **
3) **2) or (2 * 4) + 5 (or 2 * (4 + 5)).


*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700
Email: uri@speedy.net
Website: http://www.speedysoftware.com/uri/en/
<http://www.facebook.com/urievenchen>  <http://plus.google.com/+urievenchen>
  <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>

On Sun, Jun 5, 2016 at 6:05 PM, ICT Ezy <ictezy@gmail.com> wrote:

> On Sunday, June 5, 2016 at 1:06:21 PM UTC+5:30, Peter Otten wrote:
> > ICT Ezy wrote:
> >
> > >>>> 2 ** 3 ** 2
> > > Answer is 512
> > > Why not 64?
> > > Order is right-left or left-right?
> >
> > ** is a special case:
> >
> > """
> > The power operator ** binds less tightly than an arithmetic or bitwise
> unary
> > operator on its right, that is, 2**-1 is 0.5.
> > """
> > https://docs.python.org/3.5/reference/expressions.html#id21
> >
> > Here's a little demo:
> >
> > $ cat arithdemo.py
> > class A:
> >     def __init__(self, value):
> >         self.value = str(value)
> >     def __add__(self, other):
> >         return self._op(other, "+")
> >     def __pow__(self, other):
> >         return self._op(other, "**")
> >     def __repr__(self):
> >         return self.value
> >     def _op(self, other, op):
> >         return A("({} {} {})".format(self.value, op, other.value))
> > $ python3 -i arithdemo.py
> > >>> A(1) + A(2) + A(3)
> > ((1 + 2) + 3)
> > >>> A(1) ** A(2) ** A(3)
> > (1 ** (2 ** 3))
>
> Thank you very much for your explanation
> --
> https://mail.python.org/mailman/listinfo/python-list
>

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

#109535

On Sunday, June 5, 2016 at 9:36:20 PM UTC+5:30, Uri Even-Chen wrote:
> My suggestion: Never write expressions, such as  2 ** 3 ** 2 or even 2 * 4
> + 5, without parentheses. Always add parentheses - 2 ** (3 ** 2) (or (2 **
> 3) **2) or (2 * 4) + 5 (or 2 * (4 + 5)).
> 
> 
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700
> Email: uri@speedy.net
> Website: http://www.speedysoftware.com/uri/en/
> <http://www.facebook.com/urievenchen>  <http://plus.google.com/+urievenchen>
>   <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>
> 
> On Sun, Jun 5, 2016 at 6:05 PM, ICT Ezy <ictezy@gmail.com> wrote:
> 
> > On Sunday, June 5, 2016 at 1:06:21 PM UTC+5:30, Peter Otten wrote:
> > > ICT Ezy wrote:
> > >
> > > >>>> 2 ** 3 ** 2
> > > > Answer is 512
> > > > Why not 64?
> > > > Order is right-left or left-right?
> > >
> > > ** is a special case:
> > >
> > > """
> > > The power operator ** binds less tightly than an arithmetic or bitwise
> > unary
> > > operator on its right, that is, 2**-1 is 0.5.
> > > """
> > > https://docs.python.org/3.5/reference/expressions.html#id21
> > >
> > > Here's a little demo:
> > >
> > > $ cat arithdemo.py
> > > class A:
> > >     def __init__(self, value):
> > >         self.value = str(value)
> > >     def __add__(self, other):
> > >         return self._op(other, "+")
> > >     def __pow__(self, other):
> > >         return self._op(other, "**")
> > >     def __repr__(self):
> > >         return self.value
> > >     def _op(self, other, op):
> > >         return A("({} {} {})".format(self.value, op, other.value))
> > > $ python3 -i arithdemo.py
> > > >>> A(1) + A(2) + A(3)
> > > ((1 + 2) + 3)
> > > >>> A(1) ** A(2) ** A(3)
> > > (1 ** (2 ** 3))
> >
> > Thank you very much for your explanation
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

Thank you very much for your explanation

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

#109540

On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote:
> Never write expressions, such as  2 ** 3 ** 2 or even 2 * 4
> + 5, without parentheses.

That leads to the code equivalent of <http://i.dailymail.co.uk/i/pix/2011/10/13/article-2048696-03F82C520000044D-302_634x332.jpg>.

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

#109564

On Mon, Jun 6, 2016, at 01:46, Lawrence D’Oliveiro wrote:
> On Monday, June 6, 2016 at 4:06:20 AM UTC+12, Uri Even-Chen wrote:
> > Never write expressions, such as  2 ** 3 ** 2 or even 2 * 4
> > + 5, without parentheses.
> 
> That leads to the code equivalent of
> <http://i.dailymail.co.uk/i/pix/2011/10/13/article-2048696-03F82C520000044D-302_634x332.jpg>.

Okay, can we settle on, as a principle, "the basic arithmetic operators
(not to include **)  are the only ones whose precedence can be presumed
to be obvious to all readers, and other expressions may/should have
parentheses to make it more clear, even when not strictly necessary to
the meaning of the expression"?

Sure, it's obvious to _me_ that << and >> have higher precedence than &
and |, and that "and" has a higher precedence than "or", but can I
assume the other people know this? And I don't know offhand the relative
precedence of non-conceptually-related groups of operators, except that
I'm pretty sure "and" and "or" have very low precedence.

[To keep this on-topic, let's assume that this discussion has a goal of
getting something along the lines of "always/sometimes/never use
"unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
that C has lower precedence for the bitwise operators &^| than for
comparisons? That was something that tripped me up for a very long time
and undermined my confidence as to other aspects of the bitwise
operators]

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

#109566

Random832 <random832@fastmail.com>:

> Sure, it's obvious to _me_ that << and >> have higher precedence than &
> and |, and that "and" has a higher precedence than "or", but can I
> assume the other people know this?

No need to assume. Just read the spec:

   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, matrix multiplication division,
                  remainder [5]
   +x, -x, ~x     Positive, negative, bitwise NOT
   **             Exponentiation [6]
   await x        Await expression
   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

   <URL: https://docs.python.org/3/reference/expressions.html#operat
   or-precedence>

> [To keep this on-topic, let's assume that this discussion has a goal of
> getting something along the lines of "always/sometimes/never use
> "unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
> that C has lower precedence for the bitwise operators &^| than for
> comparisons? That was something that tripped me up for a very long time
> and undermined my confidence as to other aspects of the bitwise
> operators]

Yes, I happened to know that. Python's the same way.

However, no need to memorize. It's all there in the spec. Same as with
stdlib functions. Keep checking the spec.

You *can* assume other people have read the spec. Even more importantly,
you can assume the Python interpreter complies with the spec.


Marko

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

#109568

On Mon, Jun 6, 2016, at 10:22, Marko Rauhamaa wrote:
> You *can* assume other people have read the spec. Even more importantly,
> you can assume the Python interpreter complies with the spec.

I can assume the python interpreter will accept tabs as indents too,
that doesn't make it good style.

Requiring people to constantly flip between my code and the language
reference to understand it is also not good style.

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

#109570

Random832 <random832@fastmail.com>:

> On Mon, Jun 6, 2016, at 10:22, Marko Rauhamaa wrote:
>> You *can* assume other people have read the spec. Even more
>> importantly, you can assume the Python interpreter complies with the
>> spec.
>
> I can assume the python interpreter will accept tabs as indents too,
> that doesn't make it good style.
>
> Requiring people to constantly flip between my code and the language
> reference to understand it is also not good style.

I cannot guess at people's familiarity with the spec. In fact, there's
nobody in the world who masters the whole standard library, for example.
That's not a reason to start avoiding parts of the stdlib functions.

BTW, whenever I'm programming Python, I have the stdlib refererence open
next to the editor. Believe me, I keep consulting the spec all the time.

Operator precedence is a small table, of course, and it is not bad style
to assume familiarity with it.


Marko

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

#109571

On 2016-06-06, Marko Rauhamaa <marko@pacujo.net> wrote:
> Random832 <random832@fastmail.com>:
>> Sure, it's obvious to _me_ that << and >> have higher precedence than &
>> and |, and that "and" has a higher precedence than "or", but can I
>> assume the other people know this?
>
> No need to assume. Just read the spec:

The spec tells you the overlap between the set of all people who will
ever read your code and the set of people who have memorised the
entire list of operator precedences in the spec?

That's one impressive spec.

> You *can* assume other people have read the spec. Even more importantly,
> you can assume the Python interpreter complies with the spec.

Obviously the latter is true (or at least, it's true except when it's
false). The former however is not true. You should put brackets around
expressions when it's at all unclear what the meaning is. You could
think of them a bit like "active comments" I suppose.

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

#109572

Jon Ribbens <jon+usenet@unequivocal.co.uk>:

> On 2016-06-06, Marko Rauhamaa <marko@pacujo.net> wrote:
>> You *can* assume other people have read the spec. Even more
>> importantly, you can assume the Python interpreter complies with the
>> spec.
>
> Obviously the latter is true (or at least, it's true except when it's
> false). The former however is not true.

Well, of course nobody knows the whole spec. However, you should write
your code assuming they do. Different people have different gaps in
their knowledge:

 * Somebody might not be aware of chained comparisons: a < b < c

 * Somebody might not know of the "else" branch of a "for" statement.

 * Somebody might not know of the if-else expression: a if b else c

However, there's no need to avoid those facilities that are there for
people to use them. What people are unclear about they can check in the
spec, which is readily available.

> You should put brackets around expressions when it's at all unclear
> what the meaning is. You could think of them a bit like "active
> comments" I suppose.

Your code should keep noise to the minimum.


Marko

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

#109573

On 2016-06-06, Marko Rauhamaa <marko@pacujo.net> wrote:
> Jon Ribbens <jon+usenet@unequivocal.co.uk>:
>> On 2016-06-06, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> You *can* assume other people have read the spec. Even more
>>> importantly, you can assume the Python interpreter complies with the
>>> spec.
>>
>> Obviously the latter is true (or at least, it's true except when it's
>> false). The former however is not true.
>
> Well, of course nobody knows the whole spec. However, you should write
> your code assuming they do.

That sounds like bad advice to me I'm afraid. Assume they're
moderately competent, sure. Assume they know 100% of the entire spec
in all its detail? That's an assumption that will be false pretty much
100% of the time.

>> You should put brackets around expressions when it's at all unclear
>> what the meaning is. You could think of them a bit like "active
>> comments" I suppose.
>
> Your code should keep noise to the minimum.

Sensible and beneficial comments aren't "noise".

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

#109575

On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
>>> You should put brackets around expressions when it's at all unclear
>>> what the meaning is. You could think of them a bit like "active
>>> comments" I suppose.
>>
>> Your code should keep noise to the minimum.
>
> Sensible and beneficial comments aren't "noise".

In that case, please never insult the intelligence of your future
readers by including any of these parentheses:

x = 1 + (2 * 3)
value = 77 if (x % 2) else (70*7)

And if your readers have to figure out what 3**3**3 is interpreted as,
there should be an interactive interpreter around. Or here - try
something cute:

>>> 2**2**-1

ChrisA

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

#109577

On 2016-06-06, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>>>> You should put brackets around expressions when it's at all unclear
>>>> what the meaning is. You could think of them a bit like "active
>>>> comments" I suppose.
>>>
>>> Your code should keep noise to the minimum.
>>
>> Sensible and beneficial comments aren't "noise".
>
> In that case, please never insult the intelligence of your future
> readers by including any of these parentheses:
>
> x = 1 + (2 * 3)

I'm not sure what your point is. Yes, obviously you can take anything
to ridiculous extremes - that's why I said "sensible".

> value = 77 if (x % 2) else (70*7)

I'm not convinced that one isn't actually a good idea. It does seem
to aid the readability (especially if you space '70 * 7' properly).
If the expressions were any more complex then it would be even more
likely to be a good idea.

> And if your readers have to figure out what 3**3**3 is interpreted as,
> there should be an interactive interpreter around. Or here - try
> something cute:
>
>>>> 2**2**-1

I can't tell now if you're agreeing with me or disagreeing, because
you started out sounding like you were disagreeing but then provided
an example that helps prove my point.

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

#109579

On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens
<jon+usenet@unequivocal.co.uk> wrote:
> On 2016-06-06, Chris Angelico <rosuav@gmail.com> wrote:
>> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
>><jon+usenet@unequivocal.co.uk> wrote:
>>>>> You should put brackets around expressions when it's at all unclear
>>>>> what the meaning is. You could think of them a bit like "active
>>>>> comments" I suppose.
>>>>
>>>> Your code should keep noise to the minimum.
>>>
>>> Sensible and beneficial comments aren't "noise".
>>
>> In that case, please never insult the intelligence of your future
>> readers by including any of these parentheses:
>>
>> x = 1 + (2 * 3)
>
> I'm not sure what your point is. Yes, obviously you can take anything
> to ridiculous extremes - that's why I said "sensible".

Earlier in this thread, it was suggested that parens always be used,
even for this kind of example.

>> value = 77 if (x % 2) else (70*7)
>
> I'm not convinced that one isn't actually a good idea. It does seem
> to aid the readability (especially if you space '70 * 7' properly).
> If the expressions were any more complex then it would be even more
> likely to be a good idea.

Hmm, I still think not. But if you want the parens, at least
acknowledge that they're not to enforce/remind of operator precedence.

>> And if your readers have to figure out what 3**3**3 is interpreted as,
>> there should be an interactive interpreter around. Or here - try
>> something cute:
>>
>>>>> 2**2**-1
>
> I can't tell now if you're agreeing with me or disagreeing, because
> you started out sounding like you were disagreeing but then provided
> an example that helps prove my point.

My point is that if you're not sure, you grab interactive Python and
give it a quick whirl. Usually easier AND quicker than the
alternatives.

ChrisA

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

#109584

On 2016-06-06, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 7, 2016 at 2:05 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:
>> On 2016-06-06, Chris Angelico <rosuav@gmail.com> wrote:
>>> In that case, please never insult the intelligence of your future
>>> readers by including any of these parentheses:
>>>
>>> x = 1 + (2 * 3)
>>
>> I'm not sure what your point is. Yes, obviously you can take anything
>> to ridiculous extremes - that's why I said "sensible".
>
> Earlier in this thread, it was suggested that parens always be used,
> even for this kind of example.

Ok, but it wasn't me that said that, and I don't agree with it.

>>> value = 77 if (x % 2) else (70*7)
>>
>> I'm not convinced that one isn't actually a good idea. It does seem
>> to aid the readability (especially if you space '70 * 7' properly).
>> If the expressions were any more complex then it would be even more
>> likely to be a good idea.
>
> Hmm, I still think not. But if you want the parens, at least
> acknowledge that they're not to enforce/remind of operator precedence.

That depends on your point of view. I suppose the above without
parentheses could theoretically be taken to mean:
 
  value = (77 if (x % 2) else 70) * 7

although I would agree that people would be unlikely to assume that
was the meaning so they are not required under that heading.

>> I can't tell now if you're agreeing with me or disagreeing, because
>> you started out sounding like you were disagreeing but then provided
>> an example that helps prove my point.
>
> My point is that if you're not sure, you grab interactive Python and
> give it a quick whirl. Usually easier AND quicker than the
> alternatives.

It's never easier and quicker than the meaning of the code simply
being obvious by looking at it, which is the point.

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

#109581

On 2016-06-06, Chris Angelico <rosuav@gmail.com> wrote:
> On Tue, Jun 7, 2016 at 1:27 AM, Jon Ribbens
><jon+usenet@unequivocal.co.uk> wrote:

>>>> You should put brackets around expressions when it's at all
>>>> unclear what the meaning is. You could think of them a bit like
>>>> "active comments" I suppose.
>>>
>>> Your code should keep noise to the minimum.
>>
>> Sensible and beneficial comments aren't "noise".
>
> In that case, please never insult the intelligence of your future
> readers by including any of these parentheses:
>
> x = 1 + (2 * 3)
> value = 77 if (x % 2) else (70*7)

Just for the record, I don't have any problem at all with any of those
parens.  I don't think they're at all insulting, they don't slow down
comprehension, and they make clear the intent of the writer.  I'm not
sure I would include all of them if _I_ were writing the code, but in
this specific example, I think they're fine.

That said, I have seen lots of cases where fully parenthising an
expression would harm readability...

-- 
Grant Edwards               grant.b.edwards        Yow! My nose feels like a
                                  at               bad Ronald Reagan movie ...
                              gmail.com            

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

#109580

Marko Rauhamaa wrote:

> Random832 <random832@fastmail.com>:
> 
>> Sure, it's obvious to _me_ that << and >> have higher precedence than &
>> and |, and that "and" has a higher precedence than "or", but can I
>> assume the other people know this?
> 
> No need to assume. Just read the spec:
> 
>    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, matrix multiplication division,
>                   remainder [5]
>    +x, -x, ~x     Positive, negative, bitwise NOT
>    **             Exponentiation [6]
>    await x        Await expression
>    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
> 
>    <URL: https://docs.python.org/3/reference/expressions.html#operat
>    or-precedence>
> 
>> [To keep this on-topic, let's assume that this discussion has a goal of
>> getting something along the lines of "always/sometimes/never use
>> "unnecessary" parentheses" into PEP7/PEP8. Speaking of, did you know
>> that C has lower precedence for the bitwise operators &^| than for
>> comparisons? That was something that tripped me up for a very long time
>> and undermined my confidence as to other aspects of the bitwise
>> operators]
> 
> Yes, I happened to know that. Python's the same way.

It's not. From the page you linked to:

"""
Unlike C, all comparison operations in Python have the same priority, which 
is lower than that of any arithmetic, shifting or bitwise operation.
"""

> However, no need to memorize. It's all there in the spec. Same as with
> stdlib functions. Keep checking the spec.

Nah, I usually try it in the interactive interpreter:

$ python3 -c 'print(1 < 3 & 2)'
True

$ echo 'main() { printf("%d\n", 1 < 3 & 2); }' | tcc -run -
0

(tcc invocation courtesy of google/stackoverflow)

> You *can* assume other people have read the spec. Even more importantly,
> you can assume the Python interpreter complies with the spec.

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

#109585

On Mon, 6 Jun 2016 11:57 pm, Random832 wrote:

> Okay, can we settle on, as a principle, "the basic arithmetic operators
> (not to include **)  are the only ones whose precedence can be presumed
> to be obvious to all readers, 

Agreed.

> and other expressions may/should have 
> parentheses to make it more clear, even when not strictly necessary to
> the meaning of the expression"?

Sure, why not? So long as it is a "should" and not a "must".


> Sure, it's obvious to _me_ that << and >> have higher precedence than &
> and |, and that "and" has a higher precedence than "or", 

Do they?

https://docs.python.org/2/reference/expressions.html#operator-precedence

Blimey, you're right. I always thought `and` and `or` had the same
precedence. And now that I know better, I have no doubt that I will forget
it again.



-- 
Steven

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web