On Aug 1, 3:36 pm, Terry Reedy <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
