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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#96713

On 16.09.2015 19:39, Steven D'Aprano wrote:
> node = left <= ptr => right

Wow. I have absolutely no idea what this is supposed to mean. Do you 
care to elaborate?


Best,
Sven

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

#96716

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

> On 16.09.2015 19:39, Steven D'Aprano wrote:
>> node = left <= ptr => right
>
> Wow. I have absolutely no idea what this is supposed to mean. Do you
> care to elaborate?

Python is an HC Language for HC Developers.


Marko

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

#96720

On 16/09/2015 18:53, Sven R. Kunze wrote:
> On 16.09.2015 19:39, Steven D'Aprano wrote:
>> node = left <= ptr => right
>
> Wow. I have absolutely no idea what this is supposed to mean. Do you
> care to elaborate?
>
>
> Best,
> Sven

Simple, straight forward easy to read bit of Python, where is the 
problem?  node is bound to the boolean ptr is greater than or equal to 
left and right.

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

Mark Lawrence

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

#96725

On 16/09/2015 21:39, Carl Meyer wrote:
> On 09/16/2015 02:29 PM, Mark Lawrence wrote:
>> On 16/09/2015 18:53, Sven R. Kunze wrote:
>>> On 16.09.2015 19:39, Steven D'Aprano wrote:
>>>> node = left <= ptr => right
>>>
>>> Wow. I have absolutely no idea what this is supposed to mean. Do you
>>> care to elaborate?
>>>
>>>
>>> Best,
>>> Sven
>>
>> Simple, straight forward easy to read bit of Python, where is the
>> problem?  node is bound to the boolean ptr is greater than or equal to
>> left and right.
>
> Except it's a SyntaxError because Python has no => operator.
>
> Carl
>

Yes, Steven has made this mistake elsewhere.

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

Mark Lawrence

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

#96693

On 16.09.2015 18:57, 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 <

That certainly would be a fine guideline. Only use it with all operators 
the same.

Everything else might cause headaches.

Restricting it language-wise? I don't know. I have to admit I've never 
seen this in production anyway. Most languages I see people working with 
don't have this feature at all. So, they don't know it exists in Python.

Best,
Sven

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

#96695

On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
> On 16.09.2015 18:57, 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 <
>
> That certainly would be a fine guideline. Only use it with all operators 
> the same.

I find that the only times I use chaining (intentionally), are in
cases C and D.  All other instances of chaining in my code are
invariably typos/bugs.

> Everything else might cause headaches.

I'm not all that sure A and B should be allowed.

> Restricting it language-wise? I don't know. I have to admit I've never 
> seen this in production anyway. Most languages I see people working with 
> don't have this feature at all. So, they don't know it exists in Python.

I use C and D intentionally, and have tripped accidentally over other
cases.

-- 
Grant Edwards               grant.b.edwards        Yow! Hey, waiter!  I want
                                  at               a NEW SHIRT and a PONY TAIL
                              gmail.com            with lemon sauce!

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

#96700

On 9/16/2015 10:27 AM, Grant Edwards wrote:
> On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
>> On 16.09.2015 18:57, 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 <
>>
<snip>

> I'm not all that sure A and B should be allowed.

I find A convenient for initializing:

aname = bname = cname = None

Nut I don't recall ever having used is this way.

Emile

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

#96701

On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:

> On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
>> On 16.09.2015 18:57, Random832 wrote:
>>> I think that chaining should be limited to:
>>>
>>> A) all operators are "="
>>> B) all operators are "is"

[...] 
> I'm not all that sure A and B should be allowed.

You can take `x == y == z` off me when you pry it from my cold, dead hands.




-- 
Steven

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

#96703

On 2015-09-16, Steven D'Aprano <steve@pearwood.info> wrote:
> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>
>> On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
>>> On 16.09.2015 18:57, Random832 wrote:
>>>> I think that chaining should be limited to:
>>>>
>>>> A) all operators are "="
>>>> B) all operators are "is"
>
> [...] 
>> I'm not all that sure A and B should be allowed.
>
> You can take `x == y == z` off me when you pry it from my cold, dead hands.

Well, that case hadn't been mentioned yet. But, I agree that should be
added as case E and be allowed.

-- 
Grant Edwards               grant.b.edwards        Yow! ... or were you
                                  at               driving the PONTIAC that
                              gmail.com            HONKED at me in MIAMI last
                                                   Tuesday?

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

#96707

On Wed, Sep 16, 2015, at 13:44, Grant Edwards wrote:
> Well, that case hadn't been mentioned yet. But, I agree that should be
> added as case E and be allowed.

That's actually what I meant by A, I just spelled it wrong.

Multiple assignment isn't really the same construct as chained
comparisons, I didn't consider it in scope for this discussion.

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

#96708

On Wed, Sep 16, 2015 at 11:44 AM, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2015-09-16, Steven D'Aprano <steve@pearwood.info> wrote:
>> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>>
>>> On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
>>>> On 16.09.2015 18:57, Random832 wrote:
>>>>> I think that chaining should be limited to:
>>>>>
>>>>> A) all operators are "="
>>>>> B) all operators are "is"
>>
>> [...]
>>> I'm not all that sure A and B should be allowed.
>>
>> You can take `x == y == z` off me when you pry it from my cold, dead hands.
>
> Well, that case hadn't been mentioned yet. But, I agree that should be
> added as case E and be allowed.

It was mentioned as case A, albeit mistakenly using "=" (which isn't
even a comparison operator) instead of "==".

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

#96733

On Thu, 17 Sep 2015 03:44 am, Grant Edwards wrote:

> On 2015-09-16, Steven D'Aprano <steve@pearwood.info> wrote:
>> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>>
>>> On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
>>>> On 16.09.2015 18:57, Random832 wrote:
>>>>> I think that chaining should be limited to:
>>>>>
>>>>> A) all operators are "="
>>>>> B) all operators are "is"
>>
>> [...]
>>> I'm not all that sure A and B should be allowed.
>>
>> You can take `x == y == z` off me when you pry it from my cold, dead
>> hands.
> 
> Well, that case hadn't been mentioned yet. But, I agree that should be
> added as case E and be allowed.

I assumed that since we were talking about *operators* and *comparisons*,
Random832 had merely typoed "=" when (s)he meant "==", since assignment =
is neither an operator nor a comparison.

But while we're at it, you can also take away chained assignments over my
dead body -- and even then, I'll probably come back from the grave as
vengeful spirit to wreck bloody retribution on all those responsible.


-- 
Steven

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

#96718

On 16/09/2015 18:41, Emile van Sebille wrote:
> On 9/16/2015 10:27 AM, Grant Edwards wrote:
>> On 2015-09-16, Sven R. Kunze <srkunze@mail.de> wrote:
>>> On 16.09.2015 18:57, 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 <
>>>
> <snip>
>
>> I'm not all that sure A and B should be allowed.
>
> I find A convenient for initializing:
>
> aname = bname = cname = None
>
> Nut I don't recall ever having used is this way.
>
> Emile
>

You're replying to a typo, it should have been "==" not "=".

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

Mark Lawrence

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

#96717

On 16/09/2015 17: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.
>
>
> Marko
>

I disagree, perfectly logical where I sit.

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

Mark Lawrence

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

#96743

Chris Angelico wrote:
> But are there _any_ comparison operators which
> are unchainable? If not, there's no reason to disallow 'in';

My problem is that I find it difficult to remember that
Python considers 'in' to be a comparison operator.

To me, comparison is something you do between things of
the same kind, whereas 'in' is a relationship between
things of different kinds. Calling it a comparison is
like comparing apples and oranges. Or apples and
baskets of apples, or something.

-- 
Greg

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

#96748

Gregory Ewing writes:

> My problem is that I find it difficult to remember that Python
> considers 'in' to be a comparison operator.
>
> To me, comparison is something you do between things of the same kind,
> whereas 'in' is a relationship between things of different
> kinds. Calling it a comparison is like comparing apples and
> oranges. Or apples and baskets of apples, or something.

Ordinary binary operators not only combine things of the same type, they
also produce a thing of that same type. So 'in' does not fit among them
either.

I feel it's _more_ at home among comparison operators. (Hm. That's
'operator' in a different sense.)

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

#96778

On Thu, Sep 17, 2015 at 1:06 AM, Jussi Piitulainen
<harvesting@makes.email.invalid> wrote:
> Ordinary binary operators not only combine things of the same type, they
> also produce a thing of that same type. So 'in' does not fit among them
> either.
>
> I feel it's _more_ at home among comparison operators. (Hm. That's
> 'operator' in a different sense.)

Comparison operators *are* binary operators. All that "binary" means
is that it takes two arguments.

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

#96780

Ian Kelly writes:
> On Thu, Sep 17, 2015 at 1:06 AM, Jussi Piitulainen wrote:
>> Ordinary binary operators not only combine things of the same type,
>> they also produce a thing of that same type. So 'in' does not fit
>> among them either.
>>
>> I feel it's _more_ at home among comparison operators. (Hm. That's
>> 'operator' in a different sense.)
>
> Comparison operators *are* binary operators. All that "binary" means
> is that it takes two arguments.

I confused two words. It's operation I meant, not operator. A binary
_operation_ is defined as any map X * X -> X (by Lawvere and Schanuel,
Lawvere and Rosebrugh, at least; let's allow division as close enough).
(The asterisk stands for the Cartesian product. I'm too lazy to look up
the proper Unicode character for it and not willing to see a non-ASCII
symbol come back to me in a mangled form again anyway. Not today.)

Then comparisons are not binary _operations_ except in a very restricted
case. Their types are of the form X * X -> W, where W stands for a set
of truth values, {True, False}. A comparison of truth-values could be
taken as a binary operation, W * W -> W; other comparisons, under this
definition, not.

And I'm saying 'in', being truth-valued, is more like a comparison than
a proper binary operation that has its value in the same set as its two
arguments. Proper binary operations produce results that can be fed back
to them, as in either ((x - y) - z) or (x - (y -z)).

((x < y) < z) or (x < (y < z)) does not usually make sense.

((x in y) in z) more or less fails.

(x in (y in z)) fails.

Just trying to explain what I had in mind when I said that I feel that
'in' is more at home with comparisons (where it is now) than with, hm,
arithmetic operations.

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

#96784

On Thu, Sep 17, 2015, at 16:24, Jussi Piitulainen wrote:
> And I'm saying 'in', being truth-valued, is more like a comparison than
> a proper binary operation that has its value in the same set as its two
> arguments.

The problem is that except for very specialized cases (strings), the two
arguments are not (semantically, at least) in the same set as each
other, either. It may be "more" like a comparison, but it's not *really*
like either one.

> Just trying to explain what I had in mind when I said that I feel that
> 'in' is more at home with comparisons (where it is now) than with, hm,
> arithmetic operations.

Why does it have to be either one? I don't even think chaining should
work for all *actual* comparison operations.

Say you have this statement:
(1) a < b = c <= d
While it may *actually* mean this:
(2) a < b and b = c and c <= d
It *semantically* means this:
(3) a < b and a < c and a < d and b = c and b <= d and c <= d

The ones that are included logically imply the ones that are not, for
any sane definition of these operators. And if your operators *aren't*
sane, it's better to be explicit about what you are doing.

It should not be applied to any combination of operations that cannot
meaningfully be read as such a statement (e.g. mixing directions of
less/greater comparisons, or including in, is not, or != at all), or to
any values expected to have (2) not imply (3).

It being *easier to implement* to have comparison operators be a single
class and have chaining apply equally to all of them may be an excuse
for the language to allow it, but it's certainly not an excuse for
*actually* using it from a standpoint of good style and readability.

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

#96786

Random832 <random832@fastmail.com>:

> It being *easier to implement* to have comparison operators be a
> single class and have chaining apply equally to all of them may be an
> excuse for the language to allow it, but it's certainly not an excuse
> for *actually* using it from a standpoint of good style and
> readability.

In general, I don't like such caveats. Either something is in the
language or it is not.

You don't have to use all language features (I certainly don't), but if
somebody takes advantage of them, you shouldn't consider it bad style.
So if you don't like

    if prev_node is not node in excluded:
         ...

take your complaints to whoever accepted the syntax in the language.


Marko

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

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

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

csiph-web