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

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

True == 1 weirdness

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

Contents

  True == 1 weirdness "Blake T. Garretson" <blake.garretson@gmail.com> - 2015-09-16 05:16 -0700
    Re: True == 1 weirdness Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-16 15:53 +0300
      Re: True == 1 weirdness Chris Angelico <rosuav@gmail.com> - 2015-09-16 23:05 +1000
      Re: True == 1 weirdness "Blake T. Garretson" <blake.garretson@gmail.com> - 2015-09-16 06:14 -0700
      Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 10:03 -0400
        Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 03:24 +1000
          Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 13:36 -0400
          Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 19:57 +0200
          Re: True == 1 weirdness Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-16 11:57 -0600
      Re: True == 1 weirdness Chris Angelico <rosuav@gmail.com> - 2015-09-17 00:26 +1000
        Re: True == 1 weirdness Marko Rauhamaa <marko@pacujo.net> - 2015-09-16 19:16 +0300
          Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 18:37 +0200
            Re: True == 1 weirdness Marko Rauhamaa <marko@pacujo.net> - 2015-09-16 19:53 +0300
              Re: True == 1 weirdness Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-17 18:30 +1200
          Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 12:57 -0400
            Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 03:39 +1000
              Re: True == 1 weirdness Marko Rauhamaa <marko@pacujo.net> - 2015-09-16 20:42 +0300
                Re: True == 1 weirdness Emile van Sebille <emile@fenx.com> - 2015-09-16 11:46 -0700
              Re: True == 1 weirdness Grant Edwards <invalid@invalid.invalid> - 2015-09-16 17:46 +0000
                Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 20:13 +0200
                  Re: True == 1 weirdness Grant Edwards <invalid@invalid.invalid> - 2015-09-16 19:47 +0000
                    Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 21:25 +0100
                      Re: True == 1 weirdness Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-17 18:36 +1200
                    Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 23:05 +0200
                      Re: True == 1 weirdness Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-17 18:39 +1200
                        Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-17 22:46 +0200
                        Re: True == 1 weirdness Tim Chase <python.list@tim.thechases.com> - 2015-09-17 16:26 -0500
                        Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-17 23:52 +0200
                    Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 22:30 +0100
                    Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-17 00:15 +0200
                    Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-17 01:06 +0100
                      Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 11:33 +1000
                        Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-17 10:56 +0100
                          Re: True == 1 weirdness alister <alister.nospam.ware@ntlworld.com> - 2015-09-17 12:07 +0000
                            Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-17 13:27 +0100
                      Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 12:34 +1000
                    Re: True == 1 weirdness Chris Angelico <rosuav@gmail.com> - 2015-09-17 10:53 +1000
                      Re: True == 1 weirdness Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-17 18:42 +1200
                    Re: True == 1 weirdness Emile van Sebille <emile@fenx.com> - 2015-09-16 18:12 -0700
                    Re: True == 1 weirdness Tim Chase <python.list@tim.thechases.com> - 2015-09-16 18:10 -0500
              Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 19:53 +0200
                Re: True == 1 weirdness Marko Rauhamaa <marko@pacujo.net> - 2015-09-16 22:47 +0300
              Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 21:29 +0100
              Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 22:27 +0100
          Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 19:23 +0200
            Re: True == 1 weirdness Grant Edwards <invalid@invalid.invalid> - 2015-09-16 17:27 +0000
              Re: True == 1 weirdness Emile van Sebille <emile@fenx.com> - 2015-09-16 10:41 -0700
              Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 03:42 +1000
                Re: True == 1 weirdness Grant Edwards <invalid@invalid.invalid> - 2015-09-16 17:44 +0000
                  Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 13:55 -0400
                  Re: True == 1 weirdness Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-16 11:55 -0600
                  Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 11:16 +1000
              Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 21:22 +0100
          Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 21:17 +0100
        Re: True == 1 weirdness Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-17 18:24 +1200
          Re: True == 1 weirdness Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-17 10:06 +0300
            Re: True == 1 weirdness Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-17 12:49 -0600
              Re: True == 1 weirdness Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-17 23:24 +0300
                Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-17 17:26 -0400
                  Re: True == 1 weirdness Marko Rauhamaa <marko@pacujo.net> - 2015-09-18 00:38 +0300
                    Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-17 23:49 +0200
                    Re: True == 1 weirdness Chris Angelico <rosuav@gmail.com> - 2015-09-18 12:03 +1000
                  Re: True == 1 weirdness Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-18 10:10 +0300
                  Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-18 22:30 +1000
            Re: True == 1 weirdness Chris Angelico <rosuav@gmail.com> - 2015-09-18 04:57 +1000
              Re: True == 1 weirdness Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-17 23:44 +0300
      Re: True == 1 weirdness Tim Chase <python.list@tim.thechases.com> - 2015-09-16 09:38 -0500
      Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 11:40 -0400
        Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 03:33 +1000
          Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 19:41 +0200
            Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 11:22 +1000
          Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 13:47 -0400
            Re: True == 1 weirdness Grant Edwards <invalid@invalid.invalid> - 2015-09-16 17:52 +0000
            Re: True == 1 weirdness Steven D'Aprano <steve@pearwood.info> - 2015-09-17 11:25 +1000
              Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-17 02:10 -0400
                Re: True == 1 weirdness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-09-17 12:29 +0000
          Re: True == 1 weirdness Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-16 21:38 +0100
          Re: True == 1 weirdness Random832 <random832@fastmail.com> - 2015-09-16 16:55 -0400
          Re: True == 1 weirdness "Sven R. Kunze" <srkunze@mail.de> - 2015-09-16 23:03 +0200
      Re: True == 1 weirdness jmp <jeanmichel@sequans.com> - 2015-09-21 14:01 +0200
    Re: True == 1 weirdness jmp <jeanmichel@sequans.com> - 2015-09-16 15:08 +0200
      Re: True == 1 weirdness "Blake T. Garretson" <blake.garretson@gmail.com> - 2015-09-16 06:17 -0700
    Re: True == 1 weirdness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-16 09:28 -0400
    Re: True == 1 weirdness Chris Angelico <rosuav@gmail.com> - 2015-09-17 00:57 +1000

Page 1 of 5  [1] 2 3 4 5  Next page →

#96672 — True == 1 weirdness

I am maintaining some old code where the programmer used 1 for True because booleans hadn't been added to Python yet.  I'm getting some weird behaviour, so I created some simple tests to illustrate my issue.

>>> 1 in {1:1}        #test1
True
>>> 1 in {1:1} == 1   #test2
False
>>> (1 in {1:1}) == 1 #test3
True
>>> 1 in ({1:1} == 1) #test4
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'bool' is not iterable
>>>

You can see that in the first test we get True as expected.  The second test yield False, because True does not equal 1, apparently.  Fair enough.  But then the third test yields True.  Weird.  Okay, so maybe it was evaluating the right side first?  So I put the parens over to the right and it fails, so that wasn't it.  So why do the second and third test differ?

[toc] | [next] | [standalone]

#96673

Blake T. Garretson writes:

> I am maintaining some old code where the programmer used 1 for True
> because booleans hadn't been added to Python yet.  I'm getting some
> weird behaviour, so I created some simple tests to illustrate my
> issue.
>
>   >>> 1 in {1:1}        #test1
>   True
>   >>> 1 in {1:1} == 1   #test2
>   False
>   >>> (1 in {1:1}) == 1 #test3
>   True
>   >>> 1 in ({1:1} == 1) #test4
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in <module>
>   TypeError: argument of type 'bool' is not iterable
>   >>>

Ouch. I love chained comparisons more than most people, but this took a
while to decipher. I blame you! Your parentheses mis-primed me for the
wrong reading :) But now I expect to see a long thread about whether
chained comparisons are a natural thing to have in the language.

The second test, test2, is interpreted (almost) as

  >>>> (1 in {1:1}) and ({1:1} == 1)

which is obviously False.

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

#96674

On Wed, Sep 16, 2015 at 10:53 PM, Jussi Piitulainen
<harvesting@makes.email.invalid> wrote:
> Ouch. I love chained comparisons more than most people, but this took a
> while to decipher. I blame you! Your parentheses mis-primed me for the
> wrong reading :) But now I expect to see a long thread about whether
> chained comparisons are a natural thing to have in the language.
>
> The second test, test2, is interpreted (almost) as
>
>   >>>> (1 in {1:1}) and ({1:1} == 1)
>
> which is obviously False.

My view is that they should remain in the language, but that
dissimilar comparisons should raise linter warnings. I can't imagine a
sane reason for chaining 'in' and equality like that (since the RHS of
'in' will be a container, and if you're testing the whole container
for equality, you probably don't care about one member in it), but for
language consistency, it's good to support it.

Chained comparisons of the same type are a great feature:

if 1 < x < 4:

And "same type" doesn't just mean the exact same operator:

if 1 < x <= 4:

It's only when you mix them up in bizarre ways that it's getting a bit weird.

ChrisA

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

#96677

On Wednesday, September 16, 2015 at 8:54:07 AM UTC-4, Jussi Piitulainen wrote:
> The second test, test2, is interpreted (almost) as
> 
>   >>>> (1 in {1:1}) and ({1:1} == 1)
> 
> which is obviously False.

Ah, that makes sense.  It didn't occur to me that Python would interpret it that way, and I've been using Python daily for 15 years.  I try to avoid ambiguous chained comparisons, and I use parenthesis even when I don't need them for clarity.  Thanks!

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

#96680

On Wed, Sep 16, 2015, at 09:05, Chris Angelico wrote:
> My view is that they should remain in the language, but that
> dissimilar comparisons should raise linter warnings. I can't imagine a
> sane reason for chaining 'in' and equality like that (since the RHS of
> 'in' will be a container, and if you're testing the whole container
> for equality, you probably don't care about one member in it), but for
> language consistency, it's good to support it.
> 
> Chained comparisons of the same type are a great feature:

Do chained "in" comparisons ever really make sense, even when they're
all the same type?

I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true,
but how useful is it really?

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

#96694

On Thu, 17 Sep 2015 12:03 am, Random832 wrote:

> Do chained "in" comparisons ever really make sense, even when they're
> all the same type?
> 
> I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true,
> but how useful is it really?


if fly in spider in rat in cat in dog in old_woman:
    print("I don't know why she swallowed the fly")


For a less whimsical example:


if word in line in text:
    print("word in line and line in text")


But I agree with Tim Chase: I wouldn't use it, even though it's legal.


-- 
Steven

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

#96697

On Wed, Sep 16, 2015, at 13:24, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 12:03 am, Random832 wrote:
>
> if word in line in text:
>     print("word in line and line in text")
> 
> But I agree with Tim Chase: I wouldn't use it, even though it's legal.

I just had another thought on *why* the other cases make me so uneasy.

The reason this is reasonable for simple cases like a > b > c or a < b
<= c is that, in their normal meanings, these operations are transitive.
a > b and b > c implies a > c. a < b and b <= c implies a < c. This is
also a good reason for allowing "==" or "is" anywhere - because it's a
natural way to write a graph including an equivalence class: a < b == c
< d implies b < d, a < c, and a < d. So it's a natural way of writing
it. On the other hand, a in b in c doesn't imply a in c for several
common cases, and a > b < c doesn't imply anything about the
relationship between a and c, so it really shouldn't be a single
expression.

A chained comparison doesn't *actually* compare non-adjacent elements,
but with well-defined transitive relationships (or... semi-transitive?
is there a word for this? My point being that when you include some ==
or mix <= and < together, it still allows you to make some statements
about their relationships), you are essentially saying "a, b, c are
ordered". The generalization to mixing arbitrary operators loses this
aspect.

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

#96709

On 16.09.2015 19:36, Random832 wrote:
> I just had another thought on *why* the other cases make me so uneasy.
>
> The reason this is reasonable for simple cases like a > b > c or a < b
> <= c is that, in their normal meanings, these operations are transitive.
> a > b and b > c implies a > c. a < b and b <= c implies a < c. This is
> also a good reason for allowing "==" or "is" anywhere - because it's a
> natural way to write a graph including an equivalence class: a < b == c
> < d implies b < d, a < c, and a < d. So it's a natural way of writing
> it. On the other hand, a in b in c doesn't imply a in c for several
> common cases, and a > b < c doesn't imply anything about the
> relationship between a and c, so it really shouldn't be a single
> expression.
>
> A chained comparison doesn't *actually* compare non-adjacent elements,
> but with well-defined transitive relationships (or... semi-transitive?
> is there a word for this? My point being that when you include some ==
> or mix <= and < together, it still allows you to make some statements
> about their relationships), you are essentially saying "a, b, c are
> ordered". The generalization to mixing arbitrary operators loses this
> aspect.

Well said!

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

#96710

On Wed, Sep 16, 2015 at 11:24 AM, Steven D'Aprano <steve@pearwood.info> wrote:
>
> if word in line in text:
>     print("word in line and line in text")

It find it hard to imagine how one would arrive at the situation of
needing to check this.

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

#96681

On Thu, Sep 17, 2015 at 12:03 AM, Random832 <random832@fastmail.com> wrote:
> On Wed, Sep 16, 2015, at 09:05, Chris Angelico wrote:
>> My view is that they should remain in the language, but that
>> dissimilar comparisons should raise linter warnings. I can't imagine a
>> sane reason for chaining 'in' and equality like that (since the RHS of
>> 'in' will be a container, and if you're testing the whole container
>> for equality, you probably don't care about one member in it), but for
>> language consistency, it's good to support it.
>>
>> Chained comparisons of the same type are a great feature:
>
> Do chained "in" comparisons ever really make sense, even when they're
> all the same type?
>
> I mean, I suppose 1 in (1, 2) in ((1, 2), (3, 4)) is technically true,
> but how useful is it really?

Quite probably never. But are there _any_ comparison operators which
are unchainable? If not, there's no reason to disallow 'in'; this is
the distinction between language-level features and usage
recommendations. All comparisons can be chained, and the semantics of
(X op1 Y op2 Z) will always be ((X op1 Y) and (Y op2 Z)) but with Y
evaluated only once. That definition is fairly simple, and even though
it's a little wordy, it makes perfect sense; and the rule "all
comparisons" is way WAY simpler than "this specific set of chainable
operators", even if the only ones you'd ever actually want to chain
are the classic numeric operators (==, !=, <, >, <=, >=). According to
the operator precedence table [1], all comparison operators stand
together, and dividing that would mean making a once-for-everyone
decision about which are plausibly chainable. Remember, the language
rules can't know what kinds of objects we're working with; I can write
a __contains__ method that does whatever I want, but I can't decide
whether or not 'x in y in z' is evaluated as 'x in y and y in z', or
'(x in y) in z', or 'x in (y in z)', no matter what the types of x, y,
and z.

Far as I can see, the only operator that you might want to disallow
chaining on is 'in' (and its mate 'not in', of course). It isn't
common, but "x is y is z is None" is a perfectly reasonable way to
ascertain whether or not they're all None, just as "x = y = z = None"
is a perfectly reasonable way to set them all to None; the arguments
as to whether it should be "the wordy operators don't chain" or
"everything except 'in' chains" would be interminable. Much simpler to
stick with "all operators chain", which (conveniently) is status quo.
:)

ChrisA

[1] https://docs.python.org/3/reference/expressions.html#operator-precedence

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

#96688

Chris Angelico <rosuav@gmail.com>:

> Far as I can see, the only operator that you might want to disallow
> chaining on is 'in' (and its mate 'not in', of course). It isn't
> common, but "x is y is z is None" is a perfectly reasonable way to
> ascertain whether or not they're all None, just as "x = y = z = None"
> is a perfectly reasonable way to set them all to None;

Then you can have:

   first_node is not node is not last_node

No, seriously, that's not reasonable.

Frankly, I don't think chaining was all that great of an idea.


Marko

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

#96689

On 16.09.2015 18:16, Marko Rauhamaa wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Far as I can see, the only operator that you might want to disallow
>> chaining on is 'in' (and its mate 'not in', of course). It isn't
>> common, but "x is y is z is None" is a perfectly reasonable way to
>> ascertain whether or not they're all None, just as "x = y = z = None"
>> is a perfectly reasonable way to set them all to None;
> Then you can have:
>
>     first_node is not node is not last_node
>
> No, seriously, that's not reasonable.
>
> Frankly, I don't think chaining was all that great of an idea.

I like it for x < y < z.

But I agree more than this often helps confusion more than it helps clarity.

>
> Marko

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

#96690

"Sven R. Kunze" <srkunze@mail.de>:

> On 16.09.2015 18:16, Marko Rauhamaa wrote:
>> Frankly, I don't think chaining was all that great of an idea.
>
> I like it for x < y < z.
>
> But I agree more than this often helps confusion more than it helps
> clarity.

I see what you did there.


Marko

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

#96744

Marko Rauhamaa wrote:
> "Sven R. Kunze" <srkunze@mail.de>:
> 
>>But I agree more than this often helps confusion more than it helps
>>clarity.
> 
> I see what you did there.

I see what you saw what he did there.

-- 
Greg

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

#96691

On Wed, Sep 16, 2015, at 12:37, Sven R. Kunze wrote:
> I like it for x < y < z.
> 
> But I agree more than this often helps confusion more than it helps
> clarity.

I think that chaining should be limited to:

A) all operators are "="
B) all operators are "is"
C) all operators are either >= or >
D) all operators are either <= or <

There's no other scenario, if the operators have natural meanings, that
it would actually be natural to write it that way. (Actually, I'm not
entirely convinced any harm would be done by allowing you to put "is"/=
anywhere, but there certainly shouldn't be opposite direction
comparisons, "is not", !=, or "in".)

Certainly I think this should be enforced by any sort of lint tool, even
if the other uses are not actually removed from the language. I also
think it should be part of PEP 8.

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

#96698

On Thu, 17 Sep 2015 02:57 am, Random832 wrote:


> I think that chaining should be limited to:
> 
> A) all operators are "="
> B) all operators are "is"
> C) all operators are either >= or >
> D) all operators are either <= or <
> 
> There's no other scenario, if the operators have natural meanings, that
> it would actually be natural to write it that way.


0 <= x < y == z

The main reason for supporting arbitrary chained operators is that they
could be overloaded and have some meaning that makes sense:

node = left <= ptr => right



-- 
Steven

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

#96702

Steven D'Aprano <steve@pearwood.info>:

> The main reason for supporting arbitrary chained operators is that
> they could be overloaded and have some meaning that makes sense:

Operator overloading is yet another unfortunate language feature.


Marko

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

#96711

On 9/16/2015 10:42 AM, Marko Rauhamaa wrote:
> Steven D'Aprano <steve@pearwood.info>:
>
>> The main reason for supporting arbitrary chained operators is that
>> they could be overloaded and have some meaning that makes sense:
>
> Operator overloading is yet another unfortunate language feature.

dunder methods are there for consenting adults -- I don't consider it a 
wart.

Emile

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

#96704

On 2015-09-16, Steven D'Aprano <steve@pearwood.info> wrote:
> On Thu, 17 Sep 2015 02:57 am, Random832 wrote:
>
>
>> I think that chaining should be limited to:
>> 
>> A) all operators are "="
>> B) all operators are "is"
>> C) all operators are either >= or >
>> D) all operators are either <= or <
>> 
>> There's no other scenario, if the operators have natural meanings, that
>> it would actually be natural to write it that way.
>
>
> 0 <= x < y == z
>
> The main reason for supporting arbitrary chained operators is that they
> could be overloaded and have some meaning that makes sense:

In my experience, that just doesn't happen.  Yes, they can be
overloaded, but doing that and then chaining them isn't going to make
sense to anybody but the author (and temporarily even then).

> node = left <= ptr => right

Exactly. I've no clue what that means.  ;)

-- 
Grant Edwards               grant.b.edwards        Yow! Zippy's brain cells
                                  at               are straining to bridge
                              gmail.com            synapses ...

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

#96714

On 16.09.2015 19:46, Grant Edwards wrote:
> On 2015-09-16, Steven D'Aprano <steve@pearwood.info> wrote:
>> node = left <= ptr => right
> Exactly. I've no clue what that means.  ;)
>
Modern art. ;)


Best,
Sven

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web