+1 on your continued good tone when recieving negative feedback.
It’s appreciated 
1 Like
I agree with everyone that supporting x<y<z is a valuable feature.
enabling the magic method to be overloaded was briefly mentioned, and I do think it could be valuable.
besides the piping application @dg-pb wants, it would also be useful for numpy and datascience libaries, to be able to write X<Y<Z instead of (X<Y) & (Y<Z).
2 Likes
Maybe this could evaluate to (X<Y).__chain__(Y<Z) (assuming it’s defined on the result of X<Y)? Reading the rejection notice of PEP 335, it seems like something that could be accepted:
The NumPy folks brought up a somewhat separate issue: for them,
the most common use case is chained comparisons (e.g. A < B < C). If
someone wants to propose a PEP that makes this case overloadable I
might be amenable to accepting it, since chained comparisons are used
much less frequently than the and/or operators.
While it won’t allow for piping, it would have a real world use case. This crude GitHub search yields 23k results: /\(\w+ <=? \w+\) & \(\w+ <=? \w+\)/.
Edit: This idea is equivalent to the deferred PEP 535.
1 Like
This would not help piping application, but given it is quite clear that chained comparisons are staying, move in this direction makes sense.
I have made such mistake many times writing numpy.array(...)[a < b < c].
1 Like