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 c
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
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
mathemati
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 n
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 act
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*
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.
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
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* comp
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 compa
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 sa
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?
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
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 *actua
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 d
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 stan
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
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 mo
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
argumen
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
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
>>> eit
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
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
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
> 'operato
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 com
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
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 do
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 colo
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 compari
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-l
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
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
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
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
t
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* re
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
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
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
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
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
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)
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?
T
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
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"?
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
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. ;)
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
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
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
Sorr
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 y
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
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
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?
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
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
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 al
"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
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
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
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
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 c
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
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 oth
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
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:
>
>
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
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
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"
>
> [...
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
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 allowe
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
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`
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
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'
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 othe
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
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 gu
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_woma
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.
Eve
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)
"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.pytho
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 al
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"
> i
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 th
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://ma
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
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, whi
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 th
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 y
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!
--
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'
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
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
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 i
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}) ==
95 matches
Mail list logo
