Proto-PEP: Overloadable Boolean Operators
Alex Martelli
aleaxit at yahoo.com
Tue Sep 7 02:14:06 EDT 2004
Andrew Durdin <adurdin at gmail.com> wrote:
> On Tue, 07 Sep 2004 16:37:18 +1200, Greg Ewing
> <greg at cosc.canterbury.ac.nz> wrote:
> > Alex Martelli wrote:
> > > Problem is, __nonzero__ is currently
> > > typechecked -- it has to return an integer.
> >
> > Yes, that's the problem. I should probably elaborate
> > on that a bit in the PEP.
>
> That is not the only issue with __nonzero__ versus __not__ -- in some
> cases (e.g. the symbolic algebra or SQL query constructor) it is
> useful to determine when an explicit "not" operator has been used.
Yes, you're right, and my assertion was flawed. Typechecking is only
part of the issue.
> I'm not at a machine with the patch installed on it at the moment, but
> I just began to whether this patch would have an effect on expressions
> like (a < b < c) (which are also short-circuiting)... Come to think
> of it, how do objects which override __gt__ and the other comparisons
> (particularly for expression construction) work in that case?
I believe a < b < c has exactly the semantics of [but with no doube
evaluation of b...]:
(a < b) and (b < c)
Overriding _lt_ to give a print seems to confirm that:
In [1]: class chatty:
...: def __init__(self, i): self.i = i
...: def __lt__(self, other):
...: print '%d < %d' % (self.i, other.i)
...: return self.i < other.i
...:
In [2]: chatty(3) < chatty(6) < chatty(9)
3 < 6
6 < 9
Out[2]: True
In [3]: chatty(3) < chatty(16) < chatty(9)
3 < 16
16 < 9
Out[3]: False
In [4]: chatty(3) < chatty(1) < chatty(9)
3 < 1
Out[4]: False
Alex
More information about the Python-list
mailing list