Verificar si algo es una lista

Question

¿Cuál es la forma más fácil de verificar si algo es una lista?

Un método doSomething tiene los parámetros a y b. En el método, recorrerá la lista a y hará algo. Me gustaría saber si a es un list, antes de pasar, evitando un error o la desafortunada circunstancia de pasar una cadena y luego recuperar una letra de cada ciclo.

Esta pregunta debe haberse realizado antes; sin embargo, mis google me fallaron. Aclamaciones.

Answer 1

para permitir que más casos de uso, pero todavía tratar las series como escalares, no comprobar si hay un ser una lista, compruebe que no es una cadena:

if not isinstance(a, basestring): 
    ... 

Answer 2

Por lo general, se considera no un buen estilo para llevar a cabo el tipo de comprobación en Python, pero trate

if isinstance(a, list): 
    ... 

(Creo que también se puede comprobar si a.__iter__ hubiera).

Answer 3

I'd like a way to make sure a is a list, before looping through

Documente la función.

Answer 4

Typechecking daña la generalidad, simplicidad y facilidad de mantenimiento de su código. Rara vez se usa en buenos programas idiomáticos de Python.

Hay dos razones principales por las que la gente quiere typecheck:

1. Expedir errores si la persona que llama proporciona el tipo incorrecto.

   Esto no vale la pena su tiempo. Si el usuario proporciona un tipo incompatible para la operación que está realizando, ya se generará un error cuando se golpee la compatibilidad. Es preocupante que esto no ocurra inmediatamente, pero normalmente no lleva mucho tiempo y da como resultado un código que es más robusto, simple, eficiente y fácil de escribir.

   Muchas veces la gente insiste en esto con la esperanza de que puedan captar todas las tonterías que un usuario puede hacer. Si un usuario está dispuesto a hacer cosas arbitrariamente tontas, no hay nada que puedas hacer para detenerlo. Typechecking tiene principalmente el potencial de mantener a un usuario que ingresa con sus propios tipos que reemplazan a los reemplazados o cuando el usuario reconoce que su función en realidad debe ser polimórfica y proporciona algo diferente que puede aceptar la misma operación.

   Si tuviera un gran sistema en el que un montón de cosas creadas por muchas personas encajaran bien, usaría un sistema como zope.interface para probar que todo encaja bien.

2. Para hacer cosas diferentes según los tipos de argumentos recibidos.

   Esto empeora el código porque su API es inconsistente. Una función o método debería hacer una cosa, no fundamentalmente cosas diferentes. Esto termina siendo una característica que generalmente no vale la pena apoyar.

   Un escenario común es tener un argumento que puede ser un foo o una lista de foos. Una solución más limpia es simplemente aceptar una lista de foos. Tu código es más simple y más consistente.Si se trata de un caso de uso importante e importante solo para tener un foo, puede considerar tener otro método/función de conveniencia que llame al que acepta una lista de foos y no pierde nada. Proporcionar la primera API no solo habría sido más complicado y menos consistente, sino que se rompería cuando los tipos no fueran los valores exactos esperados; en Python distinguimos entre los objetos en función de sus capacidades, no sus tipos reales. Casi siempre es mejor aceptar un iterable arbitrario o una secuencia en lugar de una lista y cualquier cosa que funcione como un foo en lugar de requerir un foo en particular.

Como puede ver, no creo que ninguno de los dos motivos sea lo suficientemente convincente como para realizar una comprobación en circunstancias normales.