Re: True == 1 weirdness

[Michael Schwarz]

On 2015-09-19, at 09:19, Gregory Ewing  wrote:

> Random832 wrote:
>> I'm disputing that chained comparisons are used for the particular
>> combinations that I am actually arguing should not be used in python.
>> Such as a < b > c or a != b != c  [whereas a may or may not be equal to
>> c]
> 
> I can't remember offhand seeing a != b != c written by a
> mathematician, but if I did, I would suspect that he
> *intended* it to imply a != c, even if that's not a strict
> logical consequence of the notation.

Mathematica interprets a != b != c as "none of a, b or c are equal". See [0]. 
It does this by parsing it to Unequal[a, b, c] (square brackets are function 
calls), where Unequal then implements that operation.

Normally I'm used to Mathematica being a very consistent language. But being 
prepared by this thread, I of course wondered where the inconsistencies start 
here and whether inequalities mix well with comparisons. They don't:

While b != c != d gets parsed as this:

Unequal[b, c, d]

But a < b != c != d < e gets parsed as this:

And[Less[a, b], Unequal[b, c], Unequal[c, d], Less[d, e]]

Which means that a != b != c is interpreted differently depending on context. I 
don't think every mathematician would agree which of these interpretations make 
sense. :)

[0]: https://reference.wolfram.com/language/ref/Unequal.html


signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[jmp]

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


--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Gregory Ewing]

Random832 wrote:

I'm disputing that chained comparisons are used for the particular
combinations that I am actually arguing should not be used in python.
Such as a < b > c or a != b != c  [whereas a may or may not be equal to
c]


I can't remember offhand seeing a != b != c written by a
mathematician, but if I did, I would suspect that he
*intended* it to imply a != c, even if that's not a strict
logical consequence of the notation.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Jussi Piitulainen]

Random832 writes:

> On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
>> If a, b, c are members of a totally ordered set, so that < is
>> transitive, this is equivalent to max(a,c) < b.  But the latter makes
>> an irrelevant comparison between a and c.
>
> But *who would write that?* It's not a natural form of notation. I'm
> not saying it doesn't mean anything in Python. Obviously everything
> that is allowed means something. I'm saying no-one would write that in
> an ordinary context of human communication and expect to be
> understood.

It might be natural when discussing partial orders, where (a < b > c) is
compatible with there not being any max(a, c) or even sup(a, c) at all.

Here's a class of strings ordered by inclusion as substrings. The
comparison (u in w != u) in __lt__ came naturally when I wrote this.

class S(object):
def __init__(self, s):
self.s = s
def __lt__(self, other):
return self.s in other.s != self.s
def __eq__(self, other):
return self.s == other.s
def __str__(self):
return 'S({})'.format(repr(self.s))

And here's looking for two distinct elements that have a common proper
upper bound in a given set.

data = ('a', 'oo', 'r', 'foo', 'bar')
print(*( (x.s, y.s)
 for x in map(S, data)
 for y in map(S, data)
 for m in map(S, data)
 if y != x < m > y != x  ),
   sep = '\n')

Output:
('a', 'r')
('r', 'a')

The question is whether some such conditions might, sometimes,
somewhere, in context, look natural. I says yes.

The condition as a whole states a verbalizable relation between x, y, m:
that m is a common upper bound of distinct x, y. It's not stated whether
x < y or x > y or neither.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Terry Reedy]

On 9/18/2015 9:40 AM, Random832 wrote:


I'm disputing that chained comparisons are used for the particular
combinations that I am actually arguing should not be used in python.


You are free to dislike certain combinations, not use them yourself, and 
even request others not to use them (all in Python code).  But claiming 
that they have never been used in math is quite different.



Such asa < b > c


If a, b, c are members of a totally ordered set, so that < is 
transitive, this is equivalent to max(a,c) < b.  But the latter makes an 
irrelevant comparison between a and c.


If they are only partially ordered, so that a and c are not necessarily 
comparable, then the above is the most concise way to way what it says. 
 I believe I have seen such.



or a != b != c [whereas a may or may not be equal to c]


a != b != c != a says that all three are unequal to any of the other 
two.  I believe I have seen such, with '!=' replaced with the single 
'not equal' character.


or a in b in c.

If b and c are collections, such as sets, this is perfectly sensible. 
With 'in' replaced with the epsilon 'set membership' character, I may 
have seen such.  If 'a in b in c', then 'a in Union(c)', where Union is 
the union of all collections in c.  One might call this 
quasi-transitive.  In reverse, 'a in Union(c)' implies 'exists b, a in b 
in c'. Similarly, if 'a in b for all b in c' is equivalent to 'a in 
Intersection(c)'.



Your claim seemed to be that these combinations *are*
used, since you claimed that python implements the *same* semantics.


The semantics Python copies from math is "a op b op c == a op b and b op 
c", where 'op' is a binary predicate or comparison operator. I also 
happen to believe you are wrong in the specific examples. But the 
semantic copying would apply even if a particular combination had not 
yet ever been used.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Jussi Piitulainen]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
> If a, b, c are members of a totally ordered set, so that < is 
> transitive, this is equivalent to max(a,c) < b.  But the latter makes an 
> irrelevant comparison between a and c.

But *who would write that?* It's not a natural form of notation. I'm not
saying it doesn't mean anything in Python. Obviously everything that is
allowed means something. I'm saying no-one would write that in an
ordinary context of human communication and expect to be understood.

> > Your claim seemed to be that these combinations *are*
> > used, since you claimed that python implements the *same* semantics.
> 
> The semantics Python copies from math is "a op b op c == a op b and b op 
> c", 

I don't believe those *are* the semantics in math. I believe that in
math this notation is *specifically* meant to support "all of these
things are related to all of the others in ways that can be summarized
in a single expression" and that mixing operations in a way that does
not allow that is a misuse of the notation. In other words, any "a op b
op c" that does not allow you to make a statement on how a is related to
c is a *mistake*, because it means that you're welding together two
things that aren't logically connected to each other at all.

If there is no operator op3 where a op1 b op2 c implies a op3 c, then
you should not put a and c in the same inequality, full stop.

> where 'op' is a binary predicate or comparison operator. I also 
> happen to believe you are wrong in the specific examples. But the 
> semantic copying would apply even if a particular combination had not 
> yet ever been used.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Ian Kelly]

On Fri, Sep 18, 2015 at 1:12 PM, Random832  wrote:
> On Fri, Sep 18, 2015, at 14:24, Terry Reedy wrote:
>> The semantics Python copies from math is "a op b op c == a op b and b op
>> c",
>
> I don't believe those *are* the semantics in math. I believe that in
> math this notation is *specifically* meant to support "all of these
> things are related to all of the others in ways that can be summarized
> in a single expression" and that mixing operations in a way that does
> not allow that is a misuse of the notation. In other words, any "a op b
> op c" that does not allow you to make a statement on how a is related to
> c is a *mistake*, because it means that you're welding together two
> things that aren't logically connected to each other at all.
>
> If there is no operator op3 where a op1 b op2 c implies a op3 c, then
> you should not put a and c in the same inequality, full stop.

Whoever wrote the Wikipedia article disagrees:

https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation

Although the reference to Python leads one to suspect that this could
be based more on Python's semantics than on actual mathematics.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

On Fri, Sep 18, 2015, at 17:13, Ian Kelly wrote:
> Whoever wrote the Wikipedia article disagrees:
> 
> https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation
> 
> Although the reference to Python leads one to suspect that this could
> be based more on Python's semantics than on actual mathematics.

Also, it says "different directions", but the provided example doesn't
actually *show* different directions (i.e. mixing less-operators with
greater-operators). The provided example "a < b = c <= d" does allow you
to infer relationships between all participants: a < b, a < c, a < d, b
= c, b <= d, c <= d.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote:
> 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?

Please provide a citation for this claim.
 
> Only if the comparisons are transitive, which they may not be. 

My *entire point* is that it *shouldn't be used* for non-transitive
comparisons!!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

On Fri, 18 Sep 2015 10:47 pm, Random832 wrote:

> On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote:
>> 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?
> 
> Please provide a citation for this claim.

Really? You're disputing that chained comparisons are a standard maths
notation?

https://en.wikipedia.org/wiki/Inequality_(mathematics)#Chained_notation

Mathworld, for example, says:

Solutions to the inequality |x-a|http://mathworld.wolfram.com/Inequality.html


>> Only if the comparisons are transitive, which they may not be.
> 
> My *entire point* is that it *shouldn't be used* for non-transitive
> comparisons!!!

And my point is that there is no good reason for such a restriction, even if
it were technically possible to enforce (which it is not).

The mathematical chained notation doesn't rely on, or imply, transitivity.
Given a < b < c, *if* the operator is transitive, then AND ONLY THEN can
you conclude that a < c, but that's not implied by the chaining. It happens
to be true for real numbers, but it isn't necessarily true.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

On Fri, Sep 18, 2015, at 09:14, Steven D'Aprano wrote:
> On Fri, 18 Sep 2015 10:47 pm, Random832 wrote:
> 
> > On Fri, Sep 18, 2015, at 08:30, Steven D'Aprano wrote:
> >> 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?
> > 
> > Please provide a citation for this claim.
> 
> Really? You're disputing that chained comparisons are a standard maths
> notation?

I'm disputing that chained comparisons are used for the particular
combinations that I am actually arguing should not be used in python.
Such as a < b > c or a != b != c [whereas a may or may not be equal to
c] or a in b in c. Your claim seemed to be that these combinations *are*
used, since you claimed that python implements the *same* semantics.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Gregory Ewing]

Marko Rauhamaa wrote:

"Sven R. Kunze" :


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
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Gregory Ewing]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Gregory Ewing]

Mark Lawrence wrote:


Is it:-

modern art == crap

or

modern art = crap


It's modern == art == crap, surely?

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Gregory Ewing]

Sven R. Kunze wrote:

Btw. ASCII art is also art. So, why does Python not have ASCII art to 
define graphs and diagrams?


Nowadays it would have to support Unicode art. Mustn't
leave out all the world's non-English-speaking artists!

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Gregory Ewing]

Chris Angelico wrote:


Certainly not. A grammer is something which grams. A gram is one
thousandth of an SI unit.


Also, when ordering a hamburger in an SI-using country,
instead of a quarter-pounder you need to ask for a
125-grammer.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Jussi Piitulainen]

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.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

On 17/09/2015 02:33, Steven D'Aprano wrote:

On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:


On 16/09/2015 23:15, Sven R. Kunze wrote:

On 16.09.2015 23:30, Mark Lawrence wrote:

Barry John art is also art.  So, why does Python not have Barry John
art to define graphs and diagrams?


Too colorful for a grammer?


I'm not with you, sorry.  Is "grammer" the US spelling of the UK
"grammar"?


Mark, take a close look at Sven's name, and his email address. When your
German is better than his English, then you can pick on his spelling.



I've a German 'O' level from 42 years ago, is that close enough?

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[alister]

On Thu, 17 Sep 2015 10:56:07 +0100, Mark Lawrence wrote:

> On 17/09/2015 02:33, Steven D'Aprano wrote:
>> On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:
>>
>>> On 16/09/2015 23:15, Sven R. Kunze wrote:
 On 16.09.2015 23:30, Mark Lawrence wrote:
> Barry John art is also art.  So, why does Python not have Barry John
> art to define graphs and diagrams?

 Too colorful for a grammer?
>>>
>>> I'm not with you, sorry.  Is "grammer" the US spelling of the UK
>>> "grammar"?
>>
>> Mark, take a close look at Sven's name, and his email address. When
>> your German is better than his English, then you can pick on his
>> spelling.
>>
>>
> I've a German 'O' level from 42 years ago, is that close enough?

No




-- 
Awright, which one of you hid my PENIS ENVY?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

On 17/09/2015 13:07, alister wrote:

On Thu, 17 Sep 2015 10:56:07 +0100, Mark Lawrence wrote:


On 17/09/2015 02:33, Steven D'Aprano wrote:

On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:


On 16/09/2015 23:15, Sven R. Kunze wrote:

On 16.09.2015 23:30, Mark Lawrence wrote:

Barry John art is also art.  So, why does Python not have Barry John
art to define graphs and diagrams?


Too colorful for a grammer?


I'm not with you, sorry.  Is "grammer" the US spelling of the UK
"grammar"?


Mark, take a close look at Sven's name, and his email address. When
your German is better than his English, then you can pick on his
spelling.



I've a German 'O' level from 42 years ago, is that close enough?


No



Oh, I'm hurt :(

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Chris Angelico]

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.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Ian Kelly]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Jussi Piitulainen]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Jussi Piitulainen]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 17.09.2015 08:39, Gregory Ewing wrote:

Sven R. Kunze wrote:

Btw. ASCII art is also art. So, why does Python not have ASCII art to 
define graphs and diagrams?


Nowadays it would have to support Unicode art. Mustn't
leave out all the world's non-English-speaking artists!



How do I debug and more importantly fix graphs and diagrams made of 
non-English Unicode art? o.O

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Tim Chase]

On 2015-09-17 22:46, Sven R. Kunze wrote:
> >> Btw. ASCII art is also art. So, why does Python not have ASCII
> >> art to define graphs and diagrams?
> >
> > Nowadays it would have to support Unicode art. Mustn't
> > leave out all the world's non-English-speaking artists!
> 
> How do I debug and more importantly fix graphs and diagrams made of 
> non-English Unicode art? o.O

Um, use a decent editor?  I mean, even GNU ed(1) handles UTF-8 just
fine, as do Vim & Emacs. 

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 17.09.2015 23:38, Marko Rauhamaa wrote:

Random832 :


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
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 17.09.2015 23:26, Tim Chase wrote:

On 2015-09-17 22:46, Sven R. Kunze wrote:

Btw. ASCII art is also art. So, why does Python not have ASCII
art to define graphs and diagrams?

Nowadays it would have to support Unicode art. Mustn't
leave out all the world's non-English-speaking artists!

How do I debug and more importantly fix graphs and diagrams made of
non-English Unicode art? o.O

Um, use a decent editor?  I mean, even GNU ed(1) handles UTF-8 just
fine, as do Vim & Emacs.


Since when has debugging and fixing something to do with the encoding? I 
somehow would need to actually understand and type those characters.


Btw. PyCharm handles utf-8 as well. ;)

Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Marko Rauhamaa]

Random832 :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Chris Angelico]

On Fri, Sep 18, 2015 at 7:38 AM, Marko Rauhamaa  wrote:
> Random832 :
>
>> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

True == 1 weirdness

[Blake T. Garretson]

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 "", line 1, in 
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?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Jussi Piitulainen]

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 "", line 1, in 
>   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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Blake T. Garretson]

On Wednesday, September 16, 2015 at 9:08:54 AM UTC-4, jmp wrote:
> x = 5
> 3 < x < 10

That's a great example.  I use this case all the time and didn't think to apply 
the same principal to the in/== case.  I assumed that "in" was evaluated first, 
and then the == comparison was made.  Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Chris Angelico]

On Wed, Sep 16, 2015 at 10:53 PM, Jussi Piitulainen
 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[jmp]

On 09/16/2015 02:16 PM, Blake T. Garretson wrote:

1 in {1:1} == 1   #test2



The second test yield False, because True does not equal 1, apparently.  Fair 
enough.


No, it yields False because {1:1} == 1 is false. Test 2 looks actually like

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

Which in your example does not make any sense but think of this one:

x = 5
3 < x < 10

JM

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Blake T. Garretson]

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!
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: True == 1 weirdness

[Watson, Paul]

In terms of operator precedence, is "==" evaluated before "in"?

*-*-*- PRESBYTERIAN_HEALTHCARE_SERVICES_DISCLAIMER -*-*-*

This message originates from Presbyterian Healthcare Services or one of its 
affiliated organizations.
It contains information, which may be confidential or privileged, and is 
intended only for the
individual or entity named above. It is prohibited for anyone else to disclose, 
copy, distribute
or use the contents of this message. All personal messages express views solely 
of the sender, which are
not to be attributed to Presbyterian Healthcare Services or any of its 
affiliated organizations, and may not
be distributed without this disclaimer. If you received this message in error, 
please notify us immediately
at i...@phs.org. 

If you would like more information about Presbyterian Healthcare Services 
please visit our web site

http://www.phs.org


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Chris Angelico]

On Thu, Sep 17, 2015 at 12:03 AM, Random832  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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Tim Chase]

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



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Chris Angelico]

On Wed, Sep 16, 2015 at 11:45 PM, Watson, Paul  wrote:
> In terms of operator precedence, is "==" evaluated before "in"?

No, they're at the same precedence level. Within that, all comparison
operators are evaluated left-to-right, with the chaining that was
described earlier.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Marko Rauhamaa]

"Sven R. Kunze" :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Marko Rauhamaa]

Chris Angelico :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 16.09.2015 18:16, Marko Rauhamaa wrote:

Chris Angelico :


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


--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Ian Kelly]

On Wed, Sep 16, 2015 at 11:24 AM, Steven D'Aprano  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Marko Rauhamaa]

Steven D'Aprano :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

> On 2015-09-16, Sven R. Kunze  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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Grant Edwards]

On 2015-09-16, Steven D'Aprano  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.edwardsYow! Zippy's brain cells
  at   are straining to bridge
  gmail.comsynapses ...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Grant Edwards]

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

Ah, well I know that _that_ means:

  "I think it exemplifies the angst and conflict inherent in modern
   society".

You can say that while standing in front of any piece of modern art,
and most everybody will just nod.  Try it.
  
-- 
Grant Edwards   grant.b.edwardsYow! These PRESERVES should
  at   be FORCE-FED to PENTAGON
  gmail.comOFFICIALS!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Ian Kelly]

On Wed, Sep 16, 2015 at 11:44 AM, Grant Edwards  wrote:
> On 2015-09-16, Steven D'Aprano  wrote:
>> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>>
>>> On 2015-09-16, Sven R. Kunze  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 "==".
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 16.09.2015 19:46, Grant Edwards wrote:

On 2015-09-16, Steven D'Aprano  wrote:

node = left <= ptr => right

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


Modern art. ;)


Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

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?





--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Emile van Sebille]

On 9/16/2015 10:42 AM, Marko Rauhamaa wrote:

Steven D'Aprano :


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



--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Grant Edwards]

On 2015-09-16, Random832  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.edwardsYow! I wish I was a
  at   sex-starved manicurist
  gmail.comfound dead in the Bronx!!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Grant Edwards]

On 2015-09-16, Steven D'Aprano  wrote:
> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>
>> On 2015-09-16, Sven R. Kunze  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.edwardsYow! ... or were you
  at   driving the PONTIAC that
  gmail.comHONKED at me in MIAMI last
   Tuesday?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

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!
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Marko Rauhamaa]

"Sven R. Kunze" :

> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

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

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

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

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

On 16/09/2015 17:16, Marko Rauhamaa wrote:

Chris Angelico :


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

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

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






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

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Carl Meyer]

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



signature.asc
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 16.09.2015 21:47, Grant Edwards wrote:

On 2015-09-16, Sven R. Kunze  wrote:

On 16.09.2015 19:46, Grant Edwards wrote:

On 2015-09-16, Steven D'Aprano  wrote:


node = left <= ptr => right

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

Modern art. ;)

Ah, well I know that _that_ means:

   "I think it exemplifies the angst and conflict inherent in modern
society".

You can say that while standing in front of any piece of modern art,
and most everybody will just nod.  Try it.
   


So right. But hey, it's a sport. ;)


Btw. ASCII art is also art. So, why does Python not have ASCII art to 
define graphs and diagrams?



Best,
Sven
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

On 16/09/2015 22:05, Sven R. Kunze wrote:



On 16.09.2015 21:47, Grant Edwards wrote:

On 2015-09-16, Sven R. Kunze  wrote:

On 16.09.2015 19:46, Grant Edwards wrote:

On 2015-09-16, Steven D'Aprano  wrote:


node = left <= ptr => right

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

Modern art. ;)

Ah, well I know that _that_ means:

   "I think it exemplifies the angst and conflict inherent in modern
society".

You can say that while standing in front of any piece of modern art,
and most everybody will just nod.  Try it.


So right. But hey, it's a sport. ;)


Btw. ASCII art is also art. So, why does Python not have ASCII art to
define graphs and diagrams?

Best,
Sven


Barry John art is also art.  So, why does Python not have Barry John art 
to define graphs and diagrams?


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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

On 16/09/2015 20:47, Grant Edwards wrote:

On 2015-09-16, Sven R. Kunze  wrote:

On 16.09.2015 19:46, Grant Edwards wrote:

On 2015-09-16, Steven D'Aprano  wrote:


node = left <= ptr => right


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


Modern art. ;)


Ah, well I know that _that_ means:

   "I think it exemplifies the angst and conflict inherent in modern
society".

You can say that while standing in front of any piece of modern art,
and most everybody will just nod.  Try it.



Is it:-

modern art == crap

or

modern art = crap

?

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

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

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

On 16.09.2015 23:30, Mark Lawrence wrote:
Barry John art is also art.  So, why does Python not have Barry John 
art to define graphs and diagrams?


Too colorful for a grammer?
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Chris Angelico]

On Thu, Sep 17, 2015 at 10:06 AM, Mark Lawrence  wrote:
> On 16/09/2015 23:15, Sven R. Kunze wrote:
>>
>> On 16.09.2015 23:30, Mark Lawrence wrote:
>>>
>>> Barry John art is also art.  So, why does Python not have Barry John
>>> art to define graphs and diagrams?
>>
>>
>> Too colorful for a grammer?
>
>
> I'm not with you, sorry.  Is "grammer" the US spelling of the UK "grammar"?

Certainly not. A grammer is something which grams. A gram is one
thousandth of an SI unit.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:

> On 16/09/2015 23:15, Sven R. Kunze wrote:
>> On 16.09.2015 23:30, Mark Lawrence wrote:
>>> Barry John art is also art.  So, why does Python not have Barry John
>>> art to define graphs and diagrams?
>>
>> Too colorful for a grammer?
> 
> I'm not with you, sorry.  Is "grammer" the US spelling of the UK
> "grammar"?

Mark, take a close look at Sven's name, and his email address. When your
German is better than his English, then you can pick on his spelling.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Mark Lawrence]

On 16/09/2015 23:15, Sven R. Kunze wrote:

On 16.09.2015 23:30, Mark Lawrence wrote:

Barry John art is also art.  So, why does Python not have Barry John
art to define graphs and diagrams?


Too colorful for a grammer?


I'm not with you, sorry.  Is "grammer" the US spelling of the UK "grammar"?

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

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Emile van Sebille]

On 9/16/2015 5:53 PM, Chris Angelico wrote:

On Thu, Sep 17, 2015 at 10:06 AM, Mark Lawrence  wrote:

On 16/09/2015 23:15, Sven R. Kunze wrote:


On 16.09.2015 23:30, Mark Lawrence wrote:


Barry John art is also art.  So, why does Python not have Barry John
art to define graphs and diagrams?



Too colorful for a grammer?



I'm not with you, sorry.  Is "grammer" the US spelling of the UK "grammar"?


Certainly not. A grammer is something which grams. A gram is one
thousandth of an SI unit.


My grammer used to say some pretty colorful things.  :)

Thankfully-my-daughter-the-english-teacher-won't-see-this-ly y'rs,

Emile


--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

> On 2015-09-16, Steven D'Aprano  wrote:
>> On Thu, 17 Sep 2015 03:27 am, Grant Edwards wrote:
>>
>>> On 2015-09-16, Sven R. Kunze  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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

On Thu, 17 Sep 2015 10:06 am, Mark Lawrence wrote:

> On 16/09/2015 23:15, Sven R. Kunze wrote:
>> On 16.09.2015 23:30, Mark Lawrence wrote:
>>> Barry John art is also art.  So, why does Python not have Barry John
>>> art to define graphs and diagrams?
>>
>> Too colorful for a grammer?
> 
> I'm not with you, sorry.  Is "grammer" the US spelling of the UK
> "grammar"?


Mark, take a close look at Sven's name, and his email address. When your
German is better than his English, then you can pick on his spelling.




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Tim Chase]

On 2015-09-16 21:25, Mark Lawrence wrote:
> Is it:-
> 
> modern art == crap
> 
> or
> 
> modern art = crap

Pretty sure they're both wrong...

  modern art < crap

;-)

-tkc


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Emile van Sebille]

On 9/16/2015 10:27 AM, Grant Edwards wrote:

On 2015-09-16, Sven R. Kunze  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 <






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

--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Sven R. Kunze]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Grant Edwards]

On 2015-09-16, Sven R. Kunze  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.edwardsYow! Hey, waiter!  I want
  at   a NEW SHIRT and a PONY TAIL
  gmail.comwith lemon sauce!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Steven D'Aprano]

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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: True == 1 weirdness

[Random832]

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.
-- 
https://mail.python.org/mailman/listinfo/python-list