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

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

checking if two things do not equal None

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

Contents

  checking if two things do not equal None contact.trigon@gmail.com - 2014-03-29 11:56 -0700
    Re: checking if two things do not equal None Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-29 19:05 +0000
      Re: checking if two things do not equal None contact.trigon@gmail.com - 2014-03-29 12:23 -0700
      Re: checking if two things do not equal None Lele Gaifax <lele@metapensiero.it> - 2014-03-29 20:24 +0100
      Re: checking if two things do not equal None Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-29 22:01 +0100
        Re: checking if two things do not equal None Roy Smith <roy@panix.com> - 2014-03-29 17:07 -0400
          Re: checking if two things do not equal None Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-29 22:55 +0100
            Re: checking if two things do not equal None Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-03-29 23:02 +0100
          Re: checking if two things do not equal None Dave Angel <davea@davea.name> - 2014-03-29 18:01 -0400
            Re: checking if two things do not equal None contact.trigon@gmail.com - 2014-03-29 16:20 -0700
          Re: checking if two things do not equal None Tim Chase <python.list@tim.thechases.com> - 2014-03-29 17:36 -0500
            Re: checking if two things do not equal None Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 02:24 +0000
              Re: checking if two things do not equal None Roy Smith <roy@panix.com> - 2014-03-29 22:43 -0400
                Re: checking if two things do not equal None Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-03-29 22:04 -0500
          Re: checking if two things do not equal None Roy Smith <roy@panix.com> - 2014-03-29 18:41 -0400
          Re: checking if two things do not equal None Tim Chase <tim@thechases.com> - 2014-03-29 17:46 -0500
            Re: checking if two things do not equal None Roy Smith <roy@panix.com> - 2014-03-29 18:51 -0400
          Re: checking if two things do not equal None Chris Angelico <rosuav@gmail.com> - 2014-03-30 10:17 +1100
          Re: checking if two things do not equal None Tim Chase <python.list@tim.thechases.com> - 2014-03-29 20:19 -0500
          Re: checking if two things do not equal None Chris Angelico <rosuav@gmail.com> - 2014-03-30 12:37 +1100
          Re: checking if two things do not equal None Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 02:04 +0000
            Re: checking if two things do not equal None Chris Angelico <rosuav@gmail.com> - 2014-03-30 13:15 +1100
              Re: checking if two things do not equal None Roy Smith <roy@panix.com> - 2014-03-29 22:39 -0400
                Re: checking if two things do not equal None Rustom Mody <rustompmody@gmail.com> - 2014-03-29 19:54 -0700
                  Re: checking if two things do not equal None Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 06:08 +0000
                    Re: checking if two things do not equal None Roy Smith <roy@panix.com> - 2014-03-30 08:21 -0400
                      Re: checking if two things do not equal None MRAB <python@mrabarnett.plus.com> - 2014-03-30 14:58 +0100
                      Re: checking if two things do not equal None Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-31 11:48 +1300
                Re: checking if two things do not equal None Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-30 19:41 +1300
                  Re: checking if two things do not equal None Marko Rauhamaa <marko@pacujo.net> - 2014-03-30 10:37 +0300
              Re: checking if two things do not equal None Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-30 05:54 +0000
                Re: checking if two things do not equal None Chris Angelico <rosuav@gmail.com> - 2014-03-30 17:17 +1100
                Re: checking if two things do not equal None Ben Finney <ben+python@benfinney.id.au> - 2014-03-30 17:52 +1100
                Re: checking if two things do not equal None Chris Angelico <rosuav@gmail.com> - 2014-03-30 18:36 +1100
        Re: checking if two things do not equal None Ethan Furman <ethan@stoneleaf.us> - 2014-03-29 16:20 -0700
    Re: checking if two things do not equal None Terry Reedy <tjreedy@udel.edu> - 2014-03-29 19:02 -0400
    Re: checking if two things do not equal None Jeremy Sanders <jeremy@jeremysanders.net> - 2014-03-31 09:56 +0200
      Re: checking if two things do not equal None Abe <contact.trigon@gmail.com> - 2014-03-31 10:28 -0700
        Re: checking if two things do not equal None Moritz Emanuel Beber <moritz.beber@gmail.com> - 2014-03-31 21:22 +0200

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

#69360

On Sat, 29 Mar 2014 17:07:20 -0400, Roy Smith wrote:

> I certainly agree that things like
> 
>> if a is not b is not None: ...
> 
> belong in an obfuscated coding contest. 

Apart from the fact that I got it wrong (that's what happens when I post 
at 6am after being up all night, thanks for the correction Lele), if you 
consider chained comparisons to be "obfuscated", I think you're not 
really fluent at Python. The OP even suggested  `a != None != b` so I 
think that (s)he at least understands chained comparisons.

However, I agree with Johannes that inverted conditions (using "not") are 
sometimes harder to reason about than "regular" conditions.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#69361

On Sun, Mar 30, 2014 at 1:04 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 29 Mar 2014 17:07:20 -0400, Roy Smith wrote:
>
>> I certainly agree that things like
>>
>>> if a is not b is not None: ...
>>
>> belong in an obfuscated coding contest.
>
> Apart from the fact that I got it wrong (that's what happens when I post
> at 6am after being up all night, thanks for the correction Lele), if you
> consider chained comparisons to be "obfuscated", I think you're not
> really fluent at Python. The OP even suggested  `a != None != b` so I
> think that (s)he at least understands chained comparisons.
>
> However, I agree with Johannes that inverted conditions (using "not") are
> sometimes harder to reason about than "regular" conditions.

Chained comparisons where you're checking a single variable against
two constants make perfect sense:

2 < x < 5

Chained comparisons where you check a single constant against two
variables don't, so much:

x < 2 < y

What exactly does that mean, and why is it written that way? We can
figure out how the interpreter will parse that, but does that
correspond to the programmer's intention?

It'd be more useful but less clear if one of the conditions points the
other way:

x < 2 > y

which checks that they're both less than two, but IMO in a less-than-clear way.

ChrisA

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

#69363

In article <mailman.8709.1396145720.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> Chained comparisons where you're checking a single variable against
> two constants make perfect sense:
> 
> 2 < x < 5
> 
> Chained comparisons where you check a single constant against two
> variables don't, so much:
> 
> x < 2 < y

To me, chained comparisons make intuitive sense when they're all "<" (or 
"<=").  I just think back to junior high school algebra class, with the 
big number line above the blackboard.  Thus,

 a < b < c

means if you put a, b, and c on the number line, a is to the left of b, 
which is to the left of c.  I have no problem extending that to more 
than three values:

 a < b < c < d < e

still makes intuitive sense.  I have no particular problem with

 x < 2 < y

because it fits the same pattern.  But, if you show me

 a != None != b:

my brain just goes into overload.  Honestly, I don't even know what that 
means.  My brain keeps trying to stick a, None, and b on Mrs. Albaum's 
number line and keeps walking into the wall.  If you (the editorial you) 
tell me that my failure to grok that expression means I'm not fluent in 
Python, well then, guilty as charged.

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

#69366

On Sunday, March 30, 2014 8:09:45 AM UTC+5:30, Roy Smith wrote:
> I have no particular problem with

>  x < 2 < y

> because it fits the same pattern.  But, if you show me

>  a != None != b:

> my brain just goes into overload.  Honestly, I don't even know what that 
> means.  My brain keeps trying to stick a, None, and b on Mrs. Albaum's 
> number line and keeps walking into the wall.  If you (the editorial you) 
> tell me that my failure to grok that expression means I'm not fluent in 
> Python, well then, guilty as charged.

<Math Terminology>
A relation that is reflexive antisymmetric and transitive is a partial order
Strict order: Irreflexive asymmetric and transitive
Both are strongly related
For general R (partial) S (strict)

S from R
xSy = xRy ∧ x ≠ y
R from S
xRy = xSy ∨ x=y
</Math Terminology>

For both these chained comparisons are natural

!= is not transitive: 2 != 3 and 3  != 2 ⊬ 2 == 2

So for != chained comparisons are not natural (or IMHO appropriate)

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

#69371

On Sat, 29 Mar 2014 19:54:09 -0700, Rustom Mody wrote:

> On Sunday, March 30, 2014 8:09:45 AM UTC+5:30, Roy Smith wrote:
>> I have no particular problem with
> 
>>  x < 2 < y
> 
>> because it fits the same pattern.  But, if you show me
> 
>>  a != None != b:
> 
>> my brain just goes into overload.  Honestly, I don't even know what
>> that means.  My brain keeps trying to stick a, None, and b on Mrs.
>> Albaum's number line and keeps walking into the wall.  If you (the
>> editorial you) tell me that my failure to grok that expression means
>> I'm not fluent in Python, well then, guilty as charged.
> 
> <Math Terminology>
[...]
> So for != chained comparisons are not natural (or IMHO appropriate)

I tend to agree they're "not natural", although appropriate is another 
thing. The problem is that we tend to read something like:

    a != b != c

as "all of a, b and c are unequal", corresponding to:

    a == b == c

as "all of a, b and c are equal". But that's not what it means. It means 
that a != b and b != c, but it says nothing about a and c. And that was 
my mistake. The OP actually got it right in their first post, but 
sticking None in the middle to ensure it partakes of both comparisons.

    a is not None is not b

Still, that's not easily extended to a third item, this would be wrong:

    a is not None is not b is not c

since c only gets compared against b, not None. Better is to factor the 
"not" out:

    not (a is b is c is None)


which now should be clear: you're testing whether or not *all* of a, b 
and c are None. If you prefer:

    not all(x is None for x in (a, b, c))


Which is more readable is a matter of personal preference.

I think Johannes got it right: boolean logic is easier to reason about 
when there is a minimum of "not"s.


-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#69388

In article <5337b4e4$0$29994$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> I think Johannes got it right: boolean logic is easier to reason about 
> when there is a minimum of "not"s.

I used to do a lot of digital logic design.  In certain logic families, 
it's easier to build a NAND gate than an AND gate (and similarly, NOR is 
easier than OR).  This leads to lots of inverted logic.  Adding to the 
confusion, many designs would use "active low" logic, which means a 1 
was represented by a low voltage, and a 0 by a high voltage.  So, you 
quickly end up with gibberish like, "not active low clear nand not 
active low enable clock".  I'm glad I don't do that stuff any more.

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

#69389

On 2014-03-30 13:21, Roy Smith wrote:
> In article <5337b4e4$0$29994$c3e8da3$5496439d@news.astraweb.com>,
>   Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> I think Johannes got it right: boolean logic is easier to reason about
>> when there is a minimum of "not"s.
>
> I used to do a lot of digital logic design.  In certain logic families,
> it's easier to build a NAND gate than an AND gate (and similarly, NOR is
> easier than OR).  This leads to lots of inverted logic.  Adding to the
> confusion, many designs would use "active low" logic, which means a 1
> was represented by a low voltage, and a 0 by a high voltage.  So, you
> quickly end up with gibberish like, "not active low clear nand not
> active low enable clock".  I'm glad I don't do that stuff any more.
>
When you're building with discrete logic chips, NAND gates are useful
because you can use them as inverters too, which helps to keep the chip
count down.

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

#69397

Roy Smith wrote:
> Adding to the 
> confusion, many designs would use "active low" logic, which means a 1 
> was represented by a low voltage, and a 0 by a high voltage.  So, you 
> quickly end up with gibberish like, "not active low clear nand not 
> active low enable clock".

There are ways of dealing with that in schematic diagrams.
For exammple, if you have two active-low signals A and B
and want to express "A is active or B is active", you
draw an OR gate symbol with inversion circles on the
inputs. That's equivalent to a NAND gate, but makes the
intention clear.

Schematics drawn that way are much easier to follow than
ones that only use the inverted-output versions of the
symbols.

-- 
Greg

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

#69376

Roy Smith wrote:
> But, if you show me
> 
>  a != None != b:
> 
> my brain just goes into overload.

Chained comparisons get weird with not-equal operators.
If you see

   a == b == c

then it implies that a == c, but

   a != b != c

does *not* imply that a != c. At least it doesn't in
Python; I've never seen any mathematicians write that, so
I don't know what they would make of it.

-- 
Greg

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

#69383

Gregory Ewing <greg.ewing@canterbury.ac.nz>:

>   a != b != c
>
> does *not* imply that a != c. At least it doesn't in Python; I've
> never seen any mathematicians write that, so I don't know what they
> would make of it.

Any resemblance between mathematics notation and Python is purely
coincidental. I must admit I had missed Python's chained comparisons
until this discussion, but now I looked up the definition:

    comparison    ::=  or_expr ( comp_operator or_expr )*
    comp_operator ::=  "<" | ">" | "==" | ">=" | "<=" | "!="
                       | "is" ["not"] | ["not"] "in"

    [...]

    Formally, if a, b, c, ..., y, z are expressions and op1, op2, ...,
    opN are comparison operators, then a op1 b op2 c ... y opN z is
    equivalent to a op1 b and b op2 c and ... y opN z, except that each
    expression is evaluated at most once.


That means, in my opinion, that you should feel free to use chaining any
way you see fit. Also, the rule is crystal-clear and easy to grasp:
there's an implicit "and" there.

It's another thing, then, if it was a good idea to include chaining
there in the first place, but I trust the idea was properly vetted and
double checked against possible parsing ambiguities.

Even without chaining "is not" is a bit suspect:

    >>> False is not 0
    True
    >>> False is (not 0)
    False
    >>> False is not not not 0
      File "<stdin>", line 1
        False is not not not 0
                       ^
    SyntaxError: invalid syntax



Marko

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

#69369

On Sun, 30 Mar 2014 13:15:18 +1100, Chris Angelico wrote:

> On Sun, Mar 30, 2014 at 1:04 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Sat, 29 Mar 2014 17:07:20 -0400, Roy Smith wrote:
>>
>>> I certainly agree that things like
>>>
>>>> if a is not b is not None: ...
>>>
>>> belong in an obfuscated coding contest.
>>
>> Apart from the fact that I got it wrong (that's what happens when I
>> post at 6am after being up all night, thanks for the correction Lele),
>> if you consider chained comparisons to be "obfuscated", I think you're
>> not really fluent at Python. The OP even suggested  `a != None != b` so
>> I think that (s)he at least understands chained comparisons.
>>
>> However, I agree with Johannes that inverted conditions (using "not")
>> are sometimes harder to reason about than "regular" conditions.
> 
> Chained comparisons where you're checking a single variable against two
> constants make perfect sense:
> 
> 2 < x < 5
> 
> Chained comparisons where you check a single constant against two
> variables don't, so much:
> 
> x < 2 < y
> 
> What exactly does that mean, and why is it written that way? 

It checks that 2 is strictly bounded between x on the left and y on the 
right, i.e. that 2 is inside the open interval x...y. I don't know why 
you think that's unclear. But then I do have a maths background and I'm 
used to chaining comparisons.

Write it like this:

low = x
high = y
a = 2

low < a < high

Does that make more sense? Well-chosen names are good. The fact that a is 
a constant rather than a variable is no big deal:

low < 2 < high


> We can
> figure out how the interpreter will parse that, but does that correspond
> to the programmer's intention?

That applies to just about anything:

(x % 2 == 1) or (x > 0)

What that my intention, or did I intend to write

(x % 2 == 0) and (x < 0)


At some point you just have to accept that, in the absence of clearly 
nonsensical code or a contradiction between the documentation and the 
behaviour (i.e. a bug), the programmer will have written what she 
intended to write.


> It'd be more useful but less clear if one of the conditions points the
> other way:
> 
> x < 2 > y
> 
> which checks that they're both less than two, 

which is quite different from what you wrote the first time.


> but IMO in a less-than-clear way.

That's an understatement. If I saw code chaining comparisons in that 
fashion, I would assume the second operator > was a typo.

Chaining less-than and greater than operators should, for clarity, always 
be written in a single order. E.g. a <= b < c < d, not a <= b < d > c.

(The second contains a subtle bug too.)



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#69373

On Sun, Mar 30, 2014 at 4:54 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 30 Mar 2014 13:15:18 +1100, Chris Angelico wrote:
>
>> Chained comparisons where you're checking a single variable against two
>> constants make perfect sense:
>>
>> 2 < x < 5
>>
>> Chained comparisons where you check a single constant against two
>> variables don't, so much:
>>
>> x < 2 < y
>>
>> What exactly does that mean, and why is it written that way?
>
> It checks that 2 is strictly bounded between x on the left and y on the
> right, i.e. that 2 is inside the open interval x...y. I don't know why
> you think that's unclear. But then I do have a maths background and I'm
> used to chaining comparisons.
>
> Write it like this:
>
> low = x
> high = y
> a = 2
>
> low < a < high
>
> Does that make more sense? Well-chosen names are good. The fact that a is
> a constant rather than a variable is no big deal:
>
> low < 2 < high

The problem isn't that I can't see what the comparisons are. It makes
very good sense to bound a variable within constants; but you already
know exactly where 2 is on the number line, so asking "Is 2 between
these two variables" seems a bit odd. Maybe it's less so with the
strong mathematical background, but it seems odd to me.

>> It'd be more useful but less clear if one of the conditions points the
>> other way:
>>
>> x < 2 > y
>>
>> which checks that they're both less than two,
>
> which is quite different from what you wrote the first time.
>
>
>> but IMO in a less-than-clear way.
>
> That's an understatement. If I saw code chaining comparisons in that
> fashion, I would assume the second operator > was a typo.
>
> Chaining less-than and greater than operators should, for clarity, always
> be written in a single order. E.g. a <= b < c < d, not a <= b < d > c.
>
> (The second contains a subtle bug too.)

Agreed.

ChrisA

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

#69379

Chris Angelico <rosuav@gmail.com> writes:

> The problem isn't that I can't see what the comparisons are. It makes
> very good sense to bound a variable within constants; but you already
> know exactly where 2 is on the number line, so asking "Is 2 between
> these two variables" seems a bit odd. Maybe it's less so with the
> strong mathematical background, but it seems odd to me.

I don't feel odd about asking the question “Is 2 between these two
values?”. It's straightforward and concise. Can you explain better why
you find it odd?

-- 
 \     “You are welcome to visit the cemetery where famous Russian and |
  `\    Soviet composers, artists, and writers are buried daily except |
_o__)                   Thursday.” —Russian orthodox monastery, Moscow |
Ben Finney

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

#69382

On Sun, Mar 30, 2014 at 5:52 PM, Ben Finney <ben+python@benfinney.id.au> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> The problem isn't that I can't see what the comparisons are. It makes
>> very good sense to bound a variable within constants; but you already
>> know exactly where 2 is on the number line, so asking "Is 2 between
>> these two variables" seems a bit odd. Maybe it's less so with the
>> strong mathematical background, but it seems odd to me.
>
> I don't feel odd about asking the question “Is 2 between these two
> values?”. It's straightforward and concise. Can you explain better why
> you find it odd?

Possibly because the "variable between two constants" is something
I've done often (usually in the more explicit form of "x > min && x <
max" in a language without chained comparisons), usually
bounds-checking some value. I've never had to ask whether a single
constant has two variables, one on either side. But that's just that
I've personally never done it; it doesn't mean nobody does it, by any
means.

ChrisA

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

#69357

On 03/29/2014 02:01 PM, Johannes Bauer wrote:
> On 29.03.2014 20:05, Steven D'Aprano wrote:
>> On Sat, 29 Mar 2014 11:56:50 -0700, contact.trigon wrote:
>>
>>> if (a, b) != (None, None):
>>> or
>>> if a != None != b:
>>>
>>> Preference? Pros? Cons? Alternatives?
>>
>> if not (a is b is None): ...
>>
>> Or if you prefer:
>>
>> if a is not b is not None: ...
>
> Is this an obfuscated coding contest? Why do you opt for a solution that
> one has to at least think 2 seconds about when the simplest solution:
>
> if (a is not None) or (b is not None):
>
> is immediately understandable by everyone?

+1

--
~Ethan~

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

#69354

On 3/29/2014 2:56 PM, contact.trigon@gmail.com wrote:
> if (a, b) != (None, None):
> or
> if a != None != b:
>
> Preference? Pros? Cons? Alternatives?

if a is not None is not b
==
if a is not None and None is not b
==
if a is not None and b is not None
which is what I would write if not trying to be cute.
a < x < b is more readable as a chained comparison than the double is not.

-- 
Terry Jan Reedy

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

#69414

contact.trigon@gmail.com wrote:

> if (a, b) != (None, None):
> or
> if a != None != b:
> 
> Preference? Pros? Cons? Alternatives?

I couldn't see anyone else give this, but I like

if None not in (a, b):
 pass

Jeremy

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

#69437

> I couldn't see anyone else give this, but I like
> if None not in (a, b):

I did.

> I am now considering:

> if None not in (a,b):
> or
> if (a is not None) and (b is not None):

However, I decided to just turn the two parameters into one (sequence), since they were logically grouped anyhow.

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

#69441

On 31/03/14 19:28, Abe wrote:
>> I couldn't see anyone else give this, but I like
>> if None not in (a, b):
> I did.
>
>> I am now considering:
>> if None not in (a,b):
>> or
>> if (a is not None) and (b is not None):
That's just

if not (a is None or b is None):

but you seem to have found your way.
> However, I decided to just turn the two parameters into one (sequence), since they were logically grouped anyhow.
>
>

[toc] | [prev] | [standalone]

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

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

csiph-web