Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Gregory Ewing <greg.ewing@canterbury.ac.nz>
Newsgroups: comp.lang.python
Subject: Re: 0 + not 0
Date: Sun, 12 Jul 2015 18:12:00 +1200
Lines: 25
Message-ID: <d0eepiFo9spU1@mid.individual.net>
References: <01ec6551-1f40-42b0-9406-036030591519@googlegroups.com> <mailman.420.1436621919.3674.python-list@python.org> <not-20150711180044@ram.dialup.fu-berlin.de> <mailman.428.1436633811.3674.python-list@python.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net h7OdSGp/IaMp89ZwDIK84ANj7ITze/2saFhShPu7c3aUpR1bJj
Cancel-Lock: sha1:jkccxUuSB7xRyoBY1skbtZDuAmo=
User-Agent: Mozilla Thunderbird 1.0.5 (Macintosh/20050711)
X-Accept-Language: en-us, en
In-Reply-To: <mailman.428.1436633811.3674.python-list@python.org>
Xref: csiph.com comp.lang.python: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