[Python-ideas] PEP 355 (overloading boolean operations) and chained comparisons
Paul Moore
p.f.moore at gmail.com
Thu Oct 20 00:25:21 CEST 2011
On 19 October 2011 21:25, Raymond Hettinger <raymond.hettinger at gmail.com> wrote:
> It is harmful. The and/or operators are not currently dependent
> on the underlying objects. They can be compiled and explained
> simply in terms of if's. They are control flow, not just logic operators.
> We explain short circuiting once and everybody gets it.
> But that changes if short-circuiting only happens with certain inputs.
> It makes it much harder to look at code and know what does.
> I'm reminded of the effort to make "is" over-loadable.
> It finally go shot down because it so profoundly messed
> with people's understanding of identity and because is
> would not longer be possible to easily reason about code
> (i.e. it becomes difficult to assure that simple container code
> is correct without knowing what kind of objects were going
> to be stored in the container).
> In a way, the and/or/not overloading suggestion is worse
> than rich comparisons because even the simplest
> "a and b" expression would have to be compiled in
> a profoundly different way (and the related peephole
> optimizations would not longer be valid). Everyone
> would pay the price.
An interesting point is that while the proposal is about overloading
the logical operators, many of the arguments in favour are referring
to chained comparisons. If the rich comparison mechanisms were somehow
extended to cover chained comparisons, would that satisfy people's
requirements without needing logical operator overloading?
I'm not saying I agree with the idea of overloading chained
comparisons either, just wondering if a less ambitious proposal would
be of any value. Personally, I have no use for any of this...
Paul.
More information about the Python-ideas
mailing list