feature request: mul

[Steven Taschuk]

Quoth Michele Simionato:
> Steven Taschuk <staschuk at telusplanet.net> wrote in message news:<mailman.1055356409.24319.python-list at python.org>...
  [...]
> > This kind of thing could make for subtle bugs if you get into the
> > habit of thinking of 'sum(L)' as a logical instead of an
> > arithmetic operation.
> 
> It is difficult to get in this habit since the name 'sum' makes clear
> that you are summing numbers; I don't think it is really dangerous.
> To me 'condition' is an iterable of predicates with values True or
> False, I would not certainly consider condition=[1,-1] a good
> candidate.

Indeed, it isn't a good candidate for this use of sum().  It's
just that in all normal uses-as-booleans, [1, -1] is a perfectly
good list of two true values, so I'd expect almost any piece of
boolean machinery to treat it as such; that sum does not means it
shouldn't normally be used for this IMO.  (The exception, of
course, is when the optimization of using sum() is really needed
and the input is known to be suitably constrained.)

I think we agree here.

> The point is that there is not a builtin multi_or/multi_and.
> I am not advocating it, the use case base is too little for
> two new builtins, IMHO. 

Agreed.

(I'm not even sure that the normal use for product() -- using it
to compute a product, rather than a logical and -- is common
enough to merit a built-in.)

  [...]
-- 
Steven Taschuk             "[W]e must be very careful when we give advice
staschuk at telusplanet.net    to younger people: sometimes they follow it!"
                             -- "The Humble Programmer", Edsger Dijkstra