Agregar o multiplicar una gran lista de números en Python se puede hacer con elegancia doblando la lista con el operador de suma o multiplicación:
import functools, operator lst = range(1,100) sum = functools.reduce(operator.add, lst, 0) prod = functools.reduce(operator.mul, lst, 1) Esto necesita las funciones equivalentes de los operadores + y * que proporciona el módulo operator como operator.add y operator.mul , respectivamente.
Si quiero usar el mismo idioma con el operador or :
ingredients = ['onion', 'celery', 'cyanide', 'chicken stock'] soup_is_poisonous = functools.reduce(operator.or, map(is_poisonous, ingredients), False) ... luego descubro que el operator no tiene una función equivalente a los operadores lógicos and and or (aunque tiene uno para not lógico)
Por supuesto, puedo escribir trivialmente uno que funcione:
def operator_or(x,y): return x or y Pero me pregunto: ¿por qué no hay operator.or y operator.and en operator ? Bitwise and and or están ahí, pero no los lógicos.
Por supuesto, esto es solo una molestia menor, y la respuesta bien puede ser la misma que con la función de identidad faltante : que es fácil escribir una . Pero esto también es válido para * y + , entonces, ¿por qué la diferencia?
all es un cortocircuito lógico-y.
any es un cortocircuito lógico-o.
Supongo que no es necesario poner versiones que tomen exactamente dos argumentos (en lugar de un iterable) en el módulo del operator .
Para resumir todas sus respuestas y comentarios útiles, en orden decreciente (para mí) de convencimiento:
la adición de operator.or rompería una importante promesa hecha por el módulo
Para todos los operadores <op> que tienen funciones equivalentes operator.op en el módulo operator , se da el caso de que a <op> b es equivalente a (es decir, siempre puede, sin cambiar el comportamiento del programa, reemplazar o ser reemplazado por) operator.op(a, b) . Esta equivalencia se menciona en realidad en la cadena de documentación del módulo. Esto es imposible de hacer para los operadores and y or ya que su evaluación es un cortocircuito, mientras que las llamadas a funciones de Python siempre se evalúan después de que todos sus argumentos lo sean.
Sobre los valores True y False , | and & , por lo tanto, también el operator.and_ y operator.or_ existente (bit a bit) ya devuelven los mismos resultados (si es que devuelven algo, es decir) como or y and .
Si is_poisonous() devuelve Verdadero o Falso (no es un requisito irrazonable), podría usar
soup_is_poisonous = reduce(operator.or_, map(is_poisonous, ingredients), False) en el ejemplo de la pregunta original. Sin embargo, muchos programas de Python usan convenientemente cualquier valor de "veracidad" como True en modismos como
your_model_T_color = "black" or any_color_you_like usando | or operator.or_ en lugar de or here dará como resultado un TypeError o, peor aún, algún valor inesperado (si los operandos son int s)
Las funciones any y all se pueden usar en lugar de functools.reduce(operator.or, ....)
Este argumento no me convence: las funciones de operator se utilizan en muchos más contextos que como primer argumento para reduce . Además, any siempre devuelve True o False , no el primer valor verdadero:
any([0,0,0,5,6,7]) # returns True reduce(lambda x, y: x or y, [0,0,0,5,6,7]) # returns 5 entonces any y reduce(operator.or no sería realmente equivalente
any([x,y]) hace lo mismo (y más, ya que acepta iterables) como lo haría operator.or(x,y) .
Eso no es del todo cierto (ver arriba), any([0,5]) devuelve True mientras que operator.or(0,5) devolvería 5. Además, el número de argumentos es muy importante si usamos una función como argumento para otra función como reduce()