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

#96787

On 17.09.2015 23:38, Marko Rauhamaa wrote:
> 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.

One cannot blame it all to the languages designers. They try hard to 
optimize the programming workflows.

The responsibility is evenly split between the users and the designers 
to use and to design reasonable, maintainable and robust language features.


Best,
Sven

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

#96792

On Fri, Sep 18, 2015 at 7:38 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> 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.

Strongly disagree. We have style guides because the language allows
many things which are not good code. Given that Python programmers
can't decide on whether the line limit should be 79, 80, 100, 120, or
"79 but you can stretch to 100 if you have to", what should the syntax
be coded to? It's just as bad style to produce a 500-character line as
it is to abuse operator chaining, so should we take our complaints
about over-long lines to "whoever didn't put a length limit into
language syntax"? What about indenting with 5 spaces - should that
have been disallowed at the language level? And what about misspelled
comments - obviously they're bad style, so clearly Python should raise
SyntaxError any time it comes across one, right?

No. The language should be kept simple, and on matters of style, it
should have MORE flexibility than we use - otherwise it's a
straitjacket.

ChrisA

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

#96805

Random832 writes:

> 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.

Agreed.

(In hierarchical set theories like ZFC, the membership predicate is
between things of the same type, too: sets, the only things there are.
That's hardly relevant in a typed setting.)

>> 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.

To keep the rules simple. To keep the language comprehensible, and then
I can take the responsibility to keep my code comprehensible.

> 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

I prefer (1) with no hesitation. I start to worry about typos and
thinkos when the expression gets longer, and transitivity is such a
fundamental notion that I'd rather blame myself for not understanding
transitivity than the code for being too concise. (Also, == :)

Would really hate to be forced to spell it all out if there were more
complicated expressions in the chain.

> 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.

Yes. Those, in (1), are sane.

> 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).

I think (x != w != y) is ok to check that neither of x and y equals w.
Even (x < w > y) seems surprisingly clear to me: it's comparing the
extreme values to the middle value but not to each other. When in doubt,
I might add a comment next to the expression.

So in principle I agree. I just seem to tolerate more uses of chained
comparisons than you.

But longer chains are even rarer than 2-chains, and even 2-chains do not
happen so often, and when they do happen, they tend to be (j < k < n).
Shrug.

> 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.

It's also easier to document and comprehend, and on the whole they are a
natural class. If something does go wrong, it's nice to find out that
the explanation is simple, and not yet another special case that I was
supposed to keep in mind.

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

#96817

On Fri, 18 Sep 2015 07:26 am, Random832 wrote:

> I don't even think chaining should
> work for all *actual* comparison operations.

I don't see why. Mathematicians chain comparisons all the time. If the
language implements the same semantics as mathematicians already use, why
do you dislike that? 

I don't see the benefit in restricting the language to something less
expressive and more verbose than standard comparison chaining.


> 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

Only if the comparisons are transitive, which they may not be. If they are,
then something like this:

    a < b < c

implies a < c too. But not all comparisons are transitive.

> The ones that are included logically imply the ones that are not, for
> any sane definition of these operators. 

Transitivity is *not* required for sanity. Nontransitivity is a very useful
property for games, e.g. Rock-Paper-Scissors. It would be a very boring
game indeed if the relation

Rock < Paper < Scissors

(where < means "is beaten by") was transitive.

https://en.wikipedia.org/wiki/Nontransitive_game

Intransitivity is likewise very important in consumer preferences,
psychology, and voting (voter preferences are often nontransitive, e.g.
voters prefer the Flog-em-and-hang-em Party over the Treehugger Party, the
Treehugger Party over the Raving Monster Loony Party, and the Raving
Monster Loony Party over the Flog-em-and-hang-em Party.

[Aside: some voting systems do guarantee transitivity, but only at the cost
of some other desirable property, such as no negative votes or no dictator.
Other voting systems make nontransitive elections unlikely.]

Other real-world examples include status hierarchies and pecking orders, and
nontransitive dice. (Google it, I'm too lazy to provide a link.)


> And if your operators *aren't* 
> sane, it's better to be explicit about what you are doing.

Why? The results are perfectly well-defined however you write them.
Transitivity or not, 

"Rock beats Scissors beats Paper beats Rock"

means the same thing as

"Rock beats Scissors, and Scissors beats Paper, and Paper beats Rock"

except it's much shorter.



-- 
Steven

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

#96779

On Fri, Sep 18, 2015 at 4:49 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> 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.

I think what Jussi is saying is that int+int yields int, and
float*float yields float, and so on - but even that is true only of
the arithmetic operators, and not all of them (int/int -> float in
Py3). But generalizing from "arithmetic operators" to "ordinary
operators" is a little unfair, unless you assume that the sole purpose
of programming is to represent algebra.

ChrisA

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

#96781

Chris Angelico writes:
> On Fri, Sep 18, 2015 at 4:49 AM, Ian Kelly wrote:
>> 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 think what Jussi is saying is that int+int yields int, and
> float*float yields float, and so on - but even that is true only of
> the arithmetic operators, and not all of them (int/int -> float in
> Py3). But generalizing from "arithmetic operators" to "ordinary
> operators" is a little unfair, unless you assume that the sole purpose
> of programming is to represent algebra.

Yes, that's what I was trying to say, though I should have used the word
"operation" not "operator". The operators that denote something like
operations are routinely used to feed their values back to the same or
related operations; doing that with truth-valued operators does not
often make sense; their results are combined with and, or, and not
instead.

I can easily make up special cases myself, but now I'm trying to think
of typical uses and say that Python got this quite right.

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

#96682

On 2015-09-16 10:03, 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?

I could concoct a "useful" example where "in" is involved in a
chain, something like

   set_of_valid_ids = generate_valid_ids_maybe_negative()
   if 0 < i in set_of_valid_ids:
     do_something(i)

This would unpack as "if 0 > i and i in set_of_valid_ids".

However the "useful"ness of it doesn't outweigh the horrible
readability IMHO.  So I'd never actually *use* this, even if it might
be "useful".

-tkc

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

#96687

On Wed, Sep 16, 2015, at 10:26, Chris Angelico wrote:
> Quite probably never. But are there _any_ comparison operators which
> are unchainable? If not, there's no reason to disallow 'in'

"in" suggests a relationship between objects of different types (X and
"something that can contain X") - all the other comparison operators are
meant to work on objects of the same or similar types.

Why not make isinstance a comparison operator and have "1 instanceof int
instanceof type"? Having chaining apply to things that are not
*semantically* comparisons is just baffling.

>; 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", 

It's the same thing - you've just named that set "comparisons". I don't
think "in" is semantically a comparison at all.

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

#96696

On Thu, 17 Sep 2015 01:40 am, Random832 wrote:

> "in" suggests a relationship between objects of different types (X and
> "something that can contain X") - all the other comparison operators are
> meant to work on objects of the same or similar types.

`is` and the equality operators are intended to work on arbitrary objects,
as are their inverses `is not` and inequality.

And with operator overloading, < <=  > and => could have any meaning you
like:

graph = a => b => c <= d <= e


> Why not make isinstance a comparison operator and have "1 instanceof int
> instanceof type"? Having chaining apply to things that are not
> semantically comparisons is just baffling.

Somewhat ugly, I grant you, but if baffling? 



-- 
Steven

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

#96699

On 16.09.2015 19:33, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>
>> "in" suggests a relationship between objects of different types (X and
>> "something that can contain X") - all the other comparison operators are
>> meant to work on objects of the same or similar types.
> `is` and the equality operators are intended to work on arbitrary objects,
> as are their inverses `is not` and inequality.
>
> And with operator overloading, < <=  > and => could have any meaning you
> like:
>
> graph = a => b => c <= d <= e
>

Sorry? What are you trying to do here?

>> Why not make isinstance a comparison operator and have "1 instanceof int
>> instanceof type"? Having chaining apply to things that are not
>> semantically comparisons is just baffling.
> Somewhat ugly, I grant you, but if baffling?
>
>
>

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

#96735

On Thu, 17 Sep 2015 03:41 am, Sven R. Kunze wrote:

> On 16.09.2015 19:33, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>>
>>> "in" suggests a relationship between objects of different types (X and
>>> "something that can contain X") - all the other comparison operators are
>>> meant to work on objects of the same or similar types.
>> `is` and the equality operators are intended to work on arbitrary
>> objects, as are their inverses `is not` and inequality.
>>
>> And with operator overloading, < <=  > and => could have any meaning you
>> like:
>>
>> graph = a => b => c <= d <= e
>>
> 
> Sorry? What are you trying to do here?

Anything you like, I just made it up. That's the point: if a, b, etc have
overloaded the operators, they could mean anything. The idea I vaguely had
was that they constructed a graph, using => and <= as "arrows" so that the
above would be equivalent to the graph:

    a -> b -> c <- d <- e

(a to b, b to c; e to d, d also to c)


-- 
Steven

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

#96705

On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote:
> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
> 
> > "in" suggests a relationship between objects of different types (X and
> > "something that can contain X") - all the other comparison operators are
> > meant to work on objects of the same or similar types.
> 
> `is` and the equality operators are intended to work on arbitrary
> objects,
> as are their inverses `is not` and inequality.

But they won't return *true* unless they're the same or similar types.

> And with operator overloading, < <=  > and => could have any meaning you
> like:
> 
> graph = a => b => c <= d <= e

Are you suggesting that all objects concerned are a magical "graph node
object", the <= and [sic] => operators of which return "edge objects",
the and operator of which constructs a graph object containing all such
edges? That's *horrifying*. And won't actually work. We haven't actually
got an => operator, thankfully, and you can't overload 'and'.

I bet you could do it in C++ though.

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

#96706

On 2015-09-16, Random832 <random832@fastmail.com> wrote:
> On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote:

[...]

>> graph = a => b => c <= d <= e
>
> Are you suggesting that all objects concerned are a magical "graph node
> object", the <= and [sic] => operators of which return "edge objects",
> the and operator of which constructs a graph object containing all such
> edges? That's *horrifying*. And won't actually work. We haven't actually
> got an => operator, thankfully, and you can't overload 'and'.
>
> I bet you could do it in C++ though.

If that isn't a damning indictment, I don't know what is. :)

-- 
Grant Edwards               grant.b.edwards        Yow! I wish I was a
                                  at               sex-starved manicurist
                              gmail.com            found dead in the Bronx!!

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

#96736

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

> On Wed, Sep 16, 2015, at 13:33, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>> 
>> > "in" suggests a relationship between objects of different types (X and
>> > "something that can contain X") - all the other comparison operators
>> > are meant to work on objects of the same or similar types.
>> 
>> `is` and the equality operators are intended to work on arbitrary
>> objects,
>> as are their inverses `is not` and inequality.
> 
> But they won't return *true* unless they're the same or similar types.

So what? The intended purpose of `is` and `==` is not to return True. It is
to perform a comparison which may return False, or True.


>> And with operator overloading, < <=  > and => could have any meaning you
>> like:
>> 
>> graph = a => b => c <= d <= e
> 
> Are you suggesting that all objects concerned are a magical "graph node
> object", the <= and [sic] => operators of which return "edge objects",
> the and operator of which constructs a graph object containing all such
> edges? That's *horrifying*. And won't actually work. We haven't actually
> got an => operator, thankfully, and you can't overload 'and'.

Ah yes, well, there is that. Oops.


> I bet you could do it in C++ though.

Almost certainly.




-- 
Steven

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

#96742

On Wed, Sep 16, 2015, at 21:25, Steven D'Aprano wrote:
> So what? The intended purpose of `is` and `==` is not to return True. It
> is
> to perform a comparison which may return False, or True.

Yeah, but there's no point in doing a comparison unless you're doing it
in a context where it *might* return true. Semantics matter.

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

#96763

On Thu, 17 Sep 2015 02:10:44 -0400, Random832 wrote:

> On Wed, Sep 16, 2015, at 21:25, Steven D'Aprano wrote:
>> So what? The intended purpose of `is` and `==` is not to return True.
>> It is
>> to perform a comparison which may return False, or True.
> 
> Yeah, but there's no point in doing a comparison unless you're doing it
> in a context where it *might* return true. Semantics matter.

Have we all suddenly suffered a mass outbreak of early onset Alzheimer's 
Disease? :-) How about the most common use of `is` of all?

    if some_object is None: ...

Next thing we know, people will be claiming that => is an operator *wink*


-- 
Steven D'Aprano

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

#96721

On 16/09/2015 18:41, Sven R. Kunze wrote:
> On 16.09.2015 19:33, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 01:40 am, Random832 wrote:
>>
>>> "in" suggests a relationship between objects of different types (X and
>>> "something that can contain X") - all the other comparison operators are
>>> meant to work on objects of the same or similar types.
>> `is` and the equality operators are intended to work on arbitrary
>> objects,
>> as are their inverses `is not` and inequality.
>>
>> And with operator overloading, < <=  > and => could have any meaning you
>> like:
>>
>> graph = a => b => c <= d <= e
>>
>
> Sorry? What are you trying to do here?
>

Typo I'd hazard a guess at, should be graph = a >= b >= c <= d <= e

Assuming that I'm correct, graph is True if a is greater than or equal 
to b and b is greater than equal to c and c is less than or equal to d 
and d is less than or equal to e else False.  So where is the problem?

-- 
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]

#96722

On Wed, Sep 16, 2015, at 16:38, Mark Lawrence wrote:
> On 16/09/2015 18:41, Sven R. Kunze wrote:
> > On 16.09.2015 19:33, Steven D'Aprano wrote:
> >> And with operator overloading, < <=  > and => could have any meaning you
> >> like:
> >>
> >> graph = a => b => c <= d <= e
> >
> > Sorry? What are you trying to do here?
> 
> Typo I'd hazard a guess at, should be graph = a >= b >= c <= d <= e
> 
> Assuming that I'm correct, graph is True if a is greater than or equal 
> to b and b is greater than equal to c and c is less than or equal to d 
> and d is less than or equal to e else False.  So where is the problem?

Except in context, he was suggesting that they have a meaning other than
"greater than or equal" and "less than or equal". (see "could have any
meaning you like"). It seemed implied that he was suggesting there was
some arrangement of operator overloads that could cause this statement
to generate a directed graph with the structure shown.

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

#96723

On 16.09.2015 22:55, Random832 wrote:
> On Wed, Sep 16, 2015, at 16:38, Mark Lawrence wrote:
>> On 16/09/2015 18:41, Sven R. Kunze wrote:
>>> On 16.09.2015 19:33, Steven D'Aprano wrote:
>>>> And with operator overloading, < <=  > and => could have any meaning you
>>>> like:
>>>>
>>>> graph = a => b => c <= d <= e
>>> Sorry? What are you trying to do here?
>> Typo I'd hazard a guess at, should be graph = a >= b >= c <= d <= e
>>
>> Assuming that I'm correct, graph is True if a is greater than or equal
>> to b and b is greater than equal to c and c is less than or equal to d
>> and d is less than or equal to e else False.  So where is the problem?
> Except in context, he was suggesting that they have a meaning other than
> "greater than or equal" and "less than or equal". (see "could have any
> meaning you like"). It seemed implied that he was suggesting there was
> some arrangement of operator overloads that could cause this statement
> to generate a directed graph with the structure shown.

Yes. Let's introduce ASCII art an way to describe graphs in Python.


Best,
Sven

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

#96935

On 09/16/2015 02:53 PM, Jussi Piitulainen wrote:
>  But now I expect to see a long thread about whether
> chained comparisons are a natural thing to have in the language.

Nice forecast by the way.

JM

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

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

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

csiph-web