Boolean tests [was Re: Attack a sacred Python Cow]

[Carl Banks]

On Aug 1, 4:45 pm, Carl Banks <pavlovevide... at gmail.com> wrote:
> On Aug 1, 3:36 pm, Terry Reedy <tjre... at udel.edu> wrote:
>
>
>
> > > Nevertheless, I think this is probably the best example of the
> > > enhanced polymorphism of "if x" yet.  I'm kind of surprised no one
> > > came up with it.)
>
> > I think of Python code as 'generic' rather than 'polymorphic'.  I am not
> > sure if that is a real difference or not, since I am a bit fuzzy on the
> > meaning of 'polymorphic' in this context.
>
> > The generality of 'if x:' depends on the context.  If x is defined as a
> > number by doc or previous code (or possibly even by subsequent code),
> > then 'if x:' is equivalent to 'if x != 0:'.  At this point, it is a
> > stylistic argument which to use.
>
> > But here is an example where 'if x:' is more generic.
>
> > def solve(a,b):
> >     'a and b such that b/a exists'
> >     if a:
> >        return a/b
> >     else:
> >        raise ValueError('a not invertible, cannot solve'
>
> > Now suppose we have a matrix class (2x2 for simplicity and realism).
> > Its __bool__ (3.0) method implements 'is non-singular'.  As written
> > above, solve(mat,vec) works (with compatible mat and vec sizes), but it
> > would not with 'if a != 0:'.
>
> I see what you're saying, even though this example turns out to be
> pretty bad in practice.
>
> (Practically speaking, you hardly ever write code for both matrices
> and scalars, because the optimal way for matrices would be convoluted
> and opaque for scalars, though scalars can sometimes be fed into
> matrix code as a degenerate case.  Also, checking the condition of the
> matrix by calculating and comparing the determinant to zero is like
> comparing float equality without a tolerance, only much, much worse.)
>
> But instead of a matrix, take a vector (which has a better chance of
> being used in code designed for scalars) and define a zero-length
> vector as false, and that could be a good example.
>
> > In general, asking code to apply across numeric, container, and other
> > classes is asking too much.  Python code can be generic only within
> > protocol/interface categories such as number-like, sortable, and
> > iterable.  But making tests too specific can unnecessarily prevent even
> > that.
>
> At some point we have to throw our hands up and realize that if we're
> working with custom classes with varying degrees of nonconformance,
> there is nothing we can do that's safe.
>
> >  > Something versus nothing is a useless concept most of the time, but
> >  > occasionally finds use in human interaction cases such as printing.
>
> > It is sometimes useful within categories of classes, as in my solve example.
>
> I'm going to say no.
>
> Let's take your matrix example: you defined singularity to be false,
> but singularity can't reasonably be mapped to the concept of nothing.
> For "nothing" I would think you'd want a 0x0 matrix.  Something vs
> nothing also implies that all objects should have a boolean value.
> So, assuming boolean is connected to a matrices singularity, what
> should be the boolean value of non-square matrices?
>
> No, I'm going to have to disagree very strongly with this.
> Nonzeroness is useful.  Emptiness is useful.  Singularity a kind of
> useful.  Nothing and something are vague, ill-defined, ad hoc concepts
> that mean nothing to a computer.  Have you ever seen an algorithm that
> says "if x is something"?
>
> Something and nothing do seem to come into play occasionally in that,
> when interacting with humans (be it the user or programmer), it
> sometimes--not nearly always--makes sense to treat nonzero and empty
> in the same way.  But there's no particular reason to apply the
> concepts of something and nothing beyond this pragmatic use.
>
> Carl Banks