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

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

0 + not 0

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

Contents

  0 + not 0 candide <c.candide@laposte.net> - 2015-07-11 03:26 -0700
    Re: 0 + not 0 Chris Angelico <rosuav@gmail.com> - 2015-07-11 20:38 +1000
    Re: 0 + not 0 Irmen de Jong <irmen.NOSPAM@xs4all.nl> - 2015-07-11 12:38 +0200
      Re: 0 + not 0 Luuk <luuk@invalid.lan> - 2015-07-11 13:12 +0200
        Re: 0 + not 0 Chris Angelico <rosuav@gmail.com> - 2015-07-11 21:20 +1000
          Re: 0 + not 0 Luuk <luuk@invalid.lan> - 2015-07-11 13:30 +0200
            Re: 0 + not 0 candide <c.candide@laposte.net> - 2015-07-11 04:54 -0700
              Re: 0 + not 0 Chris Angelico <rosuav@gmail.com> - 2015-07-11 22:05 +1000
                Re: 0 + not 0 candide <c.candide@laposte.net> - 2015-07-11 06:22 -0700
          Re: 0 + not 0 candide <c.candide@laposte.net> - 2015-07-11 04:48 -0700
        Re: 0 + not 0 random832@fastmail.us - 2015-07-11 16:46 -0400
    Re: 0 + not 0 Serhiy Storchaka <storchaka@gmail.com> - 2015-07-11 16:38 +0300
      Re: 0 + not 0 candide <c.candide@laposte.net> - 2015-07-11 08:07 -0700
      Re: 0 + not 0 MRAB <python@mrabarnett.plus.com> - 2015-07-11 17:20 +0100
      Re: 0 + not 0 Ian Kelly <ian.g.kelly@gmail.com> - 2015-07-11 10:56 -0600
        Re: 0 + not 0 Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-07-12 18:12 +1200
      Re: 0 + not 0 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-11 21:05 +0100

#93672 — 0 + not 0

>>> 0 + not 0
  File "<stdin>", line 1
    0 + not 0
          ^
SyntaxError: invalid syntax
>>>


What is syntactically wrong with 0 + not 0?

[toc] | [next] | [standalone]

#93673

On Sat, Jul 11, 2015 at 8:26 PM, candide <c.candide@laposte.net> wrote:
>>>> 0 + not 0
>   File "<stdin>", line 1
>     0 + not 0
>           ^
> SyntaxError: invalid syntax
>>>>
>
>
> What is syntactically wrong with 0 + not 0?

I'm actually not sure why this can't be handled. Possibly it's a
limitation of the parser. Certainly 0 + (not 0) works just fine. This
suggests that the exponentiation operator may have been special-cased
to cope with this:

https://docs.python.org/3/reference/expressions.html#id21

So maybe there's just no corresponding special case for this - which,
I have to say, is not exactly a common construct.

ChrisA

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

#93674

On 11-7-2015 12:26, candide wrote:
>>>> 0 + not 0
>   File "<stdin>", line 1
>     0 + not 0
>           ^
> SyntaxError: invalid syntax
>>>>
> 
> 
> What is syntactically wrong with 0 + not 0?
> 

I would say that the boolean operator 'not' cannot occur in an arithmetic expression.
Maybe you meant to use the bitwise not:

>>> 0 + ~0
-1


Irmen

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

#93675

On 11-7-2015 12:38, Irmen de Jong wrote:
> On 11-7-2015 12:26, candide wrote:
>>>>> 0 + not 0
>>    File "<stdin>", line 1
>>      0 + not 0
>>            ^
>> SyntaxError: invalid syntax
>>>>>
>>
>>
>> What is syntactically wrong with 0 + not 0?
>>
>
> I would say that the boolean operator 'not' cannot occur in an arithmetic expression.
> Maybe you meant to use the bitwise not:
>
>>>> 0 + ~0
> -1
>
>
> Irmen
>

It can occur in an arithmetic expression, and 'not' has a higher 
precedence than '+'
(https://docs.python.org/2/reference/expressions.html#operator-precedence)

0 + not 0
should evalutate to
0 + True
1

just like this does:
0 + (not 0)
1


True + True
2

But, it gets confusing......
 >>> not 0 + 1
False
 >>> not 0
True
 >>> True + 1
2
 >>>

i would expect 'not 0 + 1' to return the same value as 'True + 1'

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

#93676

On Sat, Jul 11, 2015 at 9:12 PM, Luuk <luuk@invalid.lan> wrote:
> It can occur in an arithmetic expression, and 'not' has a higher precedence
> than '+'
> (https://docs.python.org/2/reference/expressions.html#operator-precedence)
>

I think you're misreading the table; 'not' has *lower* precedence than '+'.

> But, it gets confusing......
>>>> not 0 + 1
> False
>>>> not 0
> True
>>>> True + 1
> 2
>>>>
>
> i would expect 'not 0 + 1' to return the same value as 'True + 1'

(not 0 + 1) == (not (0 + 1))

ChrisA

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

#93678

On 11-7-2015 13:20, Chris Angelico wrote:
> On Sat, Jul 11, 2015 at 9:12 PM, Luuk <luuk@invalid.lan> wrote:
>> It can occur in an arithmetic expression, and 'not' has a higher precedence
>> than '+'
>> (https://docs.python.org/2/reference/expressions.html#operator-precedence)
>>
>
> I think you're misreading the table; 'not' has *lower* precedence than '+'.
>
>> But, it gets confusing......
>>>>> not 0 + 1
>> False
>>>>> not 0
>> True
>>>>> True + 1
>> 2
>>>>>
>>
>> i would expect 'not 0 + 1' to return the same value as 'True + 1'
>
> (not 0 + 1) == (not (0 + 1))
>
> ChrisA
>

But operator precedence of 'not' is higher than of '+' ????

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

#93680

Le samedi 11 juillet 2015 13:31:03 UTC+2, Luuk a écrit :

> 
> But operator precedence of 'not' is higher than of '+' ????


Right but what does this prove? For instance, unary minus has higher precedence than exponentiation but the expression

2 ** -1

doesn't raise a syntax error.

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

#93682

On Sat, Jul 11, 2015 at 9:54 PM, candide <c.candide@laposte.net> wrote:
> Le samedi 11 juillet 2015 13:31:03 UTC+2, Luuk a écrit :
>
>>
>> But operator precedence of 'not' is higher than of '+' ????
>
>
> Right but what does this prove? For instance, unary minus has higher precedence than exponentiation but the expression
>
> 2 ** -1
>
> doesn't raise a syntax error.

You'll see down below a footnote referring to this as a special case.
But I don't know the details of how it all works, so short of digging
into the source code, I can't explain this any better. There are
others on this list who can, I believe.

ChrisA

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

#93683

Le samedi 11 juillet 2015 14:05:58 UTC+2, Chris Angelico a écrit :

> You'll see down below a footnote referring to this as a special case.

I didn't spot the footnote and I don't regard it as dealing with a "special case": the footnote is paraphrasing the precedence hierarchy given by the table. I  see it more as a glose (operator exponentiation is not so common in programming languages) or, better, a warning because precedence of unary minus is "between" two "multiplicative" operators (** and *).

By the way, example provided by the doc in this footnote doesnt't properly illustrate the precedence of ** versus unary minus : whatever the precedence is, there is only one way to evaluate 2**-1. On the opposite, -1**2 (for instance) leads to two evaluations : (-1)**2 and -(1**2) and would provide an appropriate and better example.

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

#93679

Le samedi 11 juillet 2015 13:21:03 UTC+2, Chris Angelico a écrit :
> I think you're misreading the table; 'not' has *lower* precedence than '+'.
> 


Right but Python docs helps a lot in misreading ;) Following the iconicity principle, it's pretty obvious that one has to display table priority beginning with items having the highest priority, cf. for instance table operator precedence for Java provided by oracle tutorial or for the C language as given by the K&R book.

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

#93703

On Sat, Jul 11, 2015, at 07:20, Chris Angelico wrote:
> On Sat, Jul 11, 2015 at 9:12 PM, Luuk <luuk@invalid.lan> wrote:
> > It can occur in an arithmetic expression, and 'not' has a higher precedence
> > than '+'
> > (https://docs.python.org/2/reference/expressions.html#operator-precedence)
> >
> 
> I think you're misreading the table; 'not' has *lower* precedence than
> '+'.

Precedence shouldn't actually matter when resolving a unary prefix
operator on the right of a binary operator. I don't understand how this
could possibly be interpreted in a different valid way rather than being
spuriously rejected as a syntax error.

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

#93684

On 11.07.15 13:26, candide wrote:
>>>> 0 + not 0
>    File "<stdin>", line 1
>      0 + not 0
>            ^
> SyntaxError: invalid syntax
>>>>
>
>
> What is syntactically wrong with 0 + not 0?

This looks as a bug to me. Please file a report on http://bugs.python.org.

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

#93686

Le samedi 11 juillet 2015 15:38:51 UTC+2, Serhiy Storchaka a écrit :

> This looks as a bug to me. Please file a report on http://bugs.python.org.


OK, I'll report.

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

#93693

On 2015-07-11 17:02, Stefan Ram wrote:
> Serhiy Storchaka <storchaka@gmail.com> writes:
>>On 11.07.15 13:26, candide wrote:
>>>>>> 0 + not 0
>>>    File "<stdin>", line 1
>>>      0 + not 0
>>>            ^
>>> SyntaxError: invalid syntax
>>> What is syntactically wrong with 0 + not 0?
>>This looks as a bug to me. Please file a report
>
>    I look at Python 3.4.3:
>
> a_expr ::=  m_expr | a_expr "+" m_expr | a_expr "-" m_expr
>
>    So, »not 0« must be an »m_expr« when used as the right operand of »+«.
>
> m_expr ::=  u_expr | m_expr "*" u_expr | m_expr "//" u_expr | m_expr "/" u_expr | m_expr "%" u_expr
> u_expr ::=  power | "-" u_expr | "+" u_expr | "~" u_expr
> power ::=  primary ["**" u_expr]
> primary ::=  atom | attributeref | subscription | slicing | call
> atom      ::=  identifier | literal | enclosure
> enclosure ::=  parenth_form | list_display | dict_display | set_display | generator_expression | yield_atom
>
>    How can there be a »not«?
>
>    »not« is used in
>
> not_test ::=  comparison | "not" not_test
> and_test ::=  not_test | and_test "and" not_test
> or_test  ::=  and_test | or_test "or" and_test
> conditional_expression ::=  or_test ["if" or_test "else" expression]
> expression_nocond      ::=  or_test | lambda_expr_nocond
> expression             ::=  conditional_expression | lambda_expr
>
>    , but an »expression« is not an »m_expr«.
>
If "not" had the high priority of unary "-", then:

     not a < b

would be parsed as:

     (not a) < b

If you extended the OP's example to:

     0 + not 0 + 0

and permitted "not" in that position, it wouldn't be parsed as:

     0 + (not 0) + 0

but as:

     0 + (not (0 + 0))

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

#93696

On Sat, Jul 11, 2015 at 10:02 AM, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>   I look at Python 3.4.3:
>
> a_expr ::=  m_expr | a_expr "+" m_expr | a_expr "-" m_expr
>
>   So, »not 0« must be an »m_expr« when used as the right operand of »+«.
>
> m_expr ::=  u_expr | m_expr "*" u_expr | m_expr "//" u_expr | m_expr "/" u_expr | m_expr "%" u_expr
> u_expr ::=  power | "-" u_expr | "+" u_expr | "~" u_expr
> power ::=  primary ["**" u_expr]
> primary ::=  atom | attributeref | subscription | slicing | call
> atom      ::=  identifier | literal | enclosure
> enclosure ::=  parenth_form | list_display | dict_display | set_display | generator_expression | yield_atom
>
>   How can there be a »not«?
>
>   »not« is used in
>
> not_test ::=  comparison | "not" not_test
> and_test ::=  not_test | and_test "and" not_test
> or_test  ::=  and_test | or_test "or" and_test
> conditional_expression ::=  or_test ["if" or_test "else" expression]
> expression_nocond      ::=  or_test | lambda_expr_nocond
> expression             ::=  conditional_expression | lambda_expr
>
>   , but an »expression« is not an »m_expr«.

I must concur. The grammar as written does not actually produce 1 +
not 0. I think it's still worthwhile opening a bug, because the
behavior is surprising and possibly not intentional.

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

#93721

Ian Kelly wrote:
> I must concur. The grammar as written does not actually produce 1 +
> not 0. I think it's still worthwhile opening a bug, because the
> behavior is surprising and possibly not intentional.

It's almost certainly intentional. If you want

    not a + b > c

to be interpreted as

    not (a + b > c)

rather than

    (not a) + b > c

then 'not' has to be higher up in the chain of
grammar productions than the arithmetic operations.
Maintaining that while allowing 'a + not b' would
require contortions in the grammar that wouldn't be
worth the very small benefit that would be obtained.

-- 
Greg

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

#93701

On 11/07/2015 17:56, Ian Kelly wrote:
> On Sat, Jul 11, 2015 at 10:02 AM, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>    I look at Python 3.4.3:
>>
>> a_expr ::=  m_expr | a_expr "+" m_expr | a_expr "-" m_expr
>>
>>    So, »not 0« must be an »m_expr« when used as the right operand of »+«.
>>
>> m_expr ::=  u_expr | m_expr "*" u_expr | m_expr "//" u_expr | m_expr "/" u_expr | m_expr "%" u_expr
>> u_expr ::=  power | "-" u_expr | "+" u_expr | "~" u_expr
>> power ::=  primary ["**" u_expr]
>> primary ::=  atom | attributeref | subscription | slicing | call
>> atom      ::=  identifier | literal | enclosure
>> enclosure ::=  parenth_form | list_display | dict_display | set_display | generator_expression | yield_atom
>>
>>    How can there be a »not«?
>>
>>    »not« is used in
>>
>> not_test ::=  comparison | "not" not_test
>> and_test ::=  not_test | and_test "and" not_test
>> or_test  ::=  and_test | or_test "or" and_test
>> conditional_expression ::=  or_test ["if" or_test "else" expression]
>> expression_nocond      ::=  or_test | lambda_expr_nocond
>> expression             ::=  conditional_expression | lambda_expr
>>
>>    , but an »expression« is not an »m_expr«.
>
> I must concur. The grammar as written does not actually produce 1 +
> not 0. I think it's still worthwhile opening a bug, because the
> behavior is surprising and possibly not intentional.
>

http://bugs.python.org/issue24612

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [standalone]

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

csiph-web