¿Cuáles son los inconvenientes de Python? [cerrado]

Python parece estar de moda en estos días, y no sin mérito, ya que es realmente un lenguaje con el que casi disfruta que se le dé un nuevo problema para resolver. Pero, como dijo un sabio una vez (llamándolo sabio solo porque no tengo idea de quién lo dijo realmente; no estoy seguro de si era tan sabio), saber realmente un idioma no solo sabe ventajas de sintaxis, diseño, etc., pero también sus inconvenientes. Ningún idioma es perfecto, algunos son mejores que otros.

Entonces, ¿cuáles serían, en su opinión, inconvenientes objetivos de Python?

Nota: No estoy pidiendo una comparación de idioma aquí (es decir, C # es mejor que Python porque ... yadda yadda yadda), más que una opinión objetiva (hasta cierto nivel) qué características del lenguaje están mal diseñadas, si, cuáles son algunos te faltan, etc. Debe usar otro idioma como comparación, pero solo para ilustrar un punto que sería difícil de explicar de otra manera (es decir, para facilitar la comprensión)

Utilizo Python de forma regular y, en general, considero que es un lenguaje muy bueno. Sin embargo, ningún idioma es perfecto. Aquí están los inconvenientes en orden de importancia para mí personalmente:

1. Es lento. Quiero decir muy, muy lento. Muchas veces esto no importa, pero definitivamente significa que necesitará otro idioma para esos bits críticos de rendimiento.

2. Las funciones anidadas son un asco porque no se pueden modificar las variables en el ámbito externo. Editar: todavía uso Python 2 debido al soporte de la biblioteca, y este error de diseño me irrita muchísimo, pero aparentemente se solucionó en Python 3 debido a la declaración no local . No puedo esperar a que las bibliotecas que utilizo sean portadas para que esta falla pueda enviarse al montón de la historia para siempre.

3. Faltan algunas características que pueden ser útiles para la biblioteca / código genérico y, en mi humilde opinión, la simplicidad se lleva a extremos insalubres. Los más importantes en los que puedo pensar son los tipos de valores definidos por el usuario (supongo que se pueden crear con magia de metaclase, pero nunca lo he intentado) y el parámetro de función ref.

4. Está lejos del metal. ¿Necesita escribir primitivas de subprocesamiento o código de kernel o algo así? Buena suerte.

5. Si bien no me importa la falta de capacidad para detectar errores semánticos por adelantado como una compensación por el dinamismo que ofrece Python, desearía que hubiera una forma de detectar errores sintácticos y cosas tontas como escribir nombres de variables sin tener que ejecutar el código.

6. La documentación no es tan buena como los lenguajes como PHP y Java que tienen fuertes respaldos corporativos.

Odio que Python no pueda distinguir entre declaración y uso de una variable. No necesita escribir estática para que eso suceda. Sería bueno tener una manera de decir "esta es una variable que declaro deliberadamente, y tengo la intención de introducir un nuevo nombre, esto no es un error tipográfico".

Además, generalmente uso las variables de Python en un estilo de escritura única, es decir, trato las variables como inmutables y no las modifico después de su primera asignación. Gracias a características como la comprensión de la lista, esto es realmente increíblemente fácil y hace que el código fluya más fácilmente.

Sin embargo, no puedo documentar ese hecho. Nada en Python me impide sobrescribir o reutilizar variables.

En resumen, me gustaría tener dos palabras clave en el idioma: vary let. Si escribo en una variable no declarada por ninguno de esos, Python debería generar un error. Además, letdeclara las variables como de solo lectura, mientras que las varvariables son "normales".

Considere este ejemplo:

x = 42    # Error: Variable `x` undeclared

var x = 1 # OK: Declares `x` and assigns a value.
x = 42    # OK: `x` is declared and mutable.

var x = 2 # Error: Redeclaration of existing variable `x`

let y     # Error: Declaration of read-only variable `y` without value
let y = 5 # OK: Declares `y` as read-only and assigns a value.

y = 23    # Error: Variable `y` is read-only

Tenga en cuenta que los tipos siguen siendo implícitos (pero las letvariables son para todos los propósitos y tipos estánticamente tipados, ya que no pueden volver a un nuevo valor, mientras que las varvariables aún pueden tipearse dinámicamente).

Finalmente, todos los argumentos del método deberían ser automáticamente let, es decir, deberían ser de solo lectura. En general, no hay una buena razón para modificar un parámetro, excepto por el siguiente modismo:

def foo(bar = None):
    if bar == None: bar = [1, 2, 3]

Esto podría ser reemplazado por un idioma ligeramente diferente:

def foo(bar = None):
    let mybar = bar or [1, 2, 3]

Mi queja principal es el enhebrado, que no es tan eficaz en muchas circunstancias (en comparación con Java, C y otros) debido al bloqueo global del intérprete (consulte la charla "Inside the Python GIL" (enlace PDF) )

Sin embargo, hay una interfaz multiproceso que es muy fácil de usar, sin embargo, será más pesado en el uso de memoria para el mismo número de procesos frente a subprocesos, o difícil si tiene muchos datos compartidos. Sin embargo, el beneficio es que una vez que tiene un programa trabajando con múltiples procesos, puede escalar en múltiples máquinas, algo que un programa de subprocesos no puede hacer.

Realmente no estoy de acuerdo con la crítica de la documentación, creo que es excelente y mejor que la mayoría, si no todos los idiomas principales.

También puede detectar muchos de los errores de tiempo de ejecución que ejecutan pylint .

Podría decirse que la falta de tipeo estático, que puede introducir ciertas clases de errores de tiempo de ejecución , no vale la flexibilidad adicional que brinda el tipeo de pato.

Creo que las partes orientadas a objetos de Python se sienten "atornilladas". Toda la necesidad de pasar explícitamente "self" a cada método es un síntoma de que su componente OOP no se planificó expresamente , se podría decir; también muestra las reglas de alcance a veces vergonzosas de Python que fueron criticadas en otra respuesta.

Editar:

Cuando digo que las partes orientadas a objetos de Python se sienten "atornilladas", quiero decir que a veces, el lado de la POO se siente bastante inconsistente. Tomemos Ruby, por ejemplo: en Ruby, todo es un objeto, y se llama a un método usando la obj.methodsintaxis familiar (con la excepción de los operadores sobrecargados, por supuesto); en Python, todo es también un objeto, pero algunos métodos se llaman como una función; es decir, se sobrecarga __len__para devolver una longitud, pero se llama utilizando en len(obj)lugar del más obj.lengthcomún (y consistente) común en otros idiomas. Sé que hay razones detrás de esta decisión de diseño, pero no me gustan.

Además, el modelo OOP de Python no tiene ningún tipo de protección de datos, es decir, no hay miembros privados, protegidos y públicos; puedes imitarlos usando _y __frente a métodos, pero es un poco feo. Del mismo modo, Python tampoco entiende bien el aspecto de paso de mensajes de OOP.

Cosas que no me gustan de Python:

1. Enhebrado (sé que ya se ha mencionado, pero vale la pena mencionarlo en cada publicación).
2. No se admiten funciones anónimas de varias líneas ( lambdasolo puede contener una expresión).
3. Falta de una función / clase de lectura de entrada simple pero potente (como cino scanfen C ++ y C o Scanneren Java).
4. Todas las cadenas no son unicode por defecto (pero se arreglan en Python 3).

Argumentos predeterminados con tipos de datos mutables.

def foo(a, L = []):
    L.append(a)
    print L

>>> foo(1)
[1]
>>> foo(2)
[1, 2]

Suele ser el resultado de algunos errores sutiles. Creo que sería mejor si creara un nuevo objeto de lista siempre que se requiriera un argumento predeterminado (en lugar de crear un solo objeto para usar en cada llamada a la función).

Editar: no es un gran problema, pero cuando algo necesita ser referido en los documentos, generalmente significa que es un problema. Esto no debería ser obligatorio.

def foo(a, L = None):
    if L is None:
        L = []
    ...

Especialmente cuando eso debería haber sido el valor predeterminado. Es solo un comportamiento extraño que no coincide con lo que cabría esperar y no es útil para una gran cantidad de circunstancias.

Algunas de las características de Python que lo hacen tan flexible como un lenguaje de desarrollo también son vistas como inconvenientes importantes por aquellos utilizados para el análisis estático de "todo el programa" realizado por el proceso de compilación y enlace en lenguajes como C ++ y Java.

• Declaración implícita de variables locales.

Las variables locales se declaran utilizando la instrucción de asignación ordinaria. Esto significa que los enlaces de variables en cualquier otro ámbito requieren una anotación explícita para ser recogida por el compilador (declaraciones globales y no locales para ámbitos externos, notación de acceso a atributos, por ejemplo, ámbitos). Esto reduce enormemente la cantidad de repeticiones necesarias cuando se programa, pero significa que se necesitan herramientas de análisis estático de terceros (como pyflakes) para realizar comprobaciones manejadas por el compilador en lenguajes que requieren declaraciones de variables explícitas.

• "Parche de mono" es compatible

El contenido de los módulos, los objetos de clase e incluso el espacio de nombres incorporado se puede modificar en tiempo de ejecución. Esto es enormemente poderoso, permitiendo muchas técnicas extremadamente útiles. Sin embargo, esta flexibilidad significa que Python no ofrece algunas características comunes a los lenguajes OO de tipo estático. En particular, el parámetro "self" para los métodos de instancia es explícito en lugar de implícito (dado que los "métodos" no tienen que definirse dentro de una clase, se pueden agregar más tarde modificando la clase, lo que significa que no es particularmente práctico para pasar la referencia de instancia implícitamente) y los controles de acceso a los atributos no se pueden aplicar fácilmente en función de si el código está "dentro" o "fuera" de la clase (ya que esa distinción solo existe mientras se ejecuta la definición de clase).

• Lejos del metal

Esto también es cierto para muchos otros lenguajes de alto nivel, pero Python tiende a abstraer la mayoría de los detalles del hardware. Los lenguajes de programación de sistemas como C y C ++ siguen siendo mucho más adecuados para manejar el acceso directo al hardware (sin embargo, Python hablará con ellos con gusto a través de los módulos de extensión CPython o, de manera más portátil, a través de la ctypesbiblioteca).

1. Usar sangría para bloques de código en lugar de {} / begin-end, lo que sea.
2. Cada lenguaje moderno más nuevo tiene un alcance léxico adecuado, pero no Python (ver más abajo).
3. Documentos caóticos (compárelos con la documentación de Perl5, que es excelente).
4. Camisa de fuerza (solo hay una forma de hacerlo).

Ejemplo de alcance roto; transcripción de la sesión de intérprete:

>>> x=0
>>> def f():
...     x+=3
...     print x
... 
>>> f()
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment

globaly nonlocalse han introducido palabras clave para corregir esta estupidez de diseño.

Me parece muy inquietante la combinación de sintaxis orientada a objetos this.method()y procesal / funcional de Python method(this):

x = [0, 1, 2, 3, 4]
x.count(1)
len(x)
any(x)
x.reverse()
reversed(x)
x.sort()
sorted(x)

Esto es particularmente malo porque una gran cantidad de funciones (en lugar de métodos) simplemente se vuelcan en el espacio de nombres global : métodos relacionados con listas, cadenas, números, constructores, metaprogramación, todo mezclado en una gran lista ordenada alfabéticamente.

Como mínimo, los lenguajes funcionales como F # tienen todas las funciones correctamente espaciadas en los módulos:

List.map(x)
List.reversed(x)
List.any(x)

Entonces no están todos juntos. Además, este es un estándar seguido en toda la biblioteca, por lo que al menos es consistente.

Entiendo las razones para hacer la función vs método , pero todavía creo que es una mala idea mezclarlos de esta manera. Sería mucho más feliz si se siguiera la sintaxis del método, al menos para las operaciones comunes:

x.count(1)
x.len()
x.any()
x.reverse()
x.reversed()
x.sort()
x.sorted()

Si los métodos están mutando o no, tenerlos como métodos en el objeto tiene varias ventajas:

• Lugar único para buscar las operaciones "comunes" en un tipo de datos: otras bibliotecas / etc. pueden tener otras cosas elegantes que pueden hacer a los tipos de datos, pero las operaciones "predeterminadas" están en los métodos del objeto.
• No es necesario seguir repitiendo Moduleal llamar Module.method(x). Tomando el ejemplo de la lista funcional anterior, ¿por qué tengo que seguir diciendo Listuna y otra vez? ¡Debe saber que es un Listy no quiero llamar a la Navigation.map()función en él! El uso de la x.map()sintaxis lo mantiene SECO y sin ambigüedades.

Y, por supuesto, tiene ventajas sobre la forma de hacerlo de poner todo en el espacio de nombres global . No es que la forma actual sea incapaz de hacer las cosas. Incluso es bastante conciso ( len(lst)), ¡ya que nada tiene espacio de nombres! Entiendo las ventajas de usar funciones (comportamiento predeterminado, etc.) sobre los métodos, pero todavía no me gusta.

Es solo desordenado. Y en grandes proyectos, el desorden es tu peor enemigo.

Falta de homoiconicidad .

Python tuvo que esperar 3.x para agregar una palabra clave "con". En cualquier lenguaje homoicónico podría haberse agregado trivialmente en una biblioteca.

La mayoría de los otros problemas que he visto en las respuestas son de uno de 3 tipos:

1) Cosas que se pueden arreglar con herramientas (p. Ej., Pyflakes) 2) Detalles de implementación (GIL, rendimiento) 3) Cosas que se pueden arreglar con estándares de codificación (es decir, características que la gente desearía que no estuvieran allí)

# 2 no es un problema con el idioma, IMO # 1 y # 3 no son problemas serios.

Python es mi lenguaje favorito, ya que es muy expresivo, pero aún así evita que cometas demasiados errores. Todavía tengo algunas cosas que me molestan:

• No hay funciones anónimas reales. Lambda puede usarse para funciones de una sola declaración, y la withdeclaración puede usarse para muchas cosas en las que usaría un bloque de código en Ruby. Pero en algunas situaciones hace que las cosas sean un poco más torpes de lo que deberían ser. (Lejos de ser tan torpe como sería en Java, pero aún así ...)

• Alguna confusión en la relación entre módulos y archivos. Ejecutar "python foo.py" desde la línea de comandos es diferente de "import foo". Las importaciones relativas en Python 2.x también pueden causar problemas. Aún así, los módulos de Python son mucho mejores que las características correspondientes de C, C ++ y Ruby.

• Explícito self. Aunque entiendo algunas de las razones, y aunque uso Python a diario, tiendo a cometer el error de olvidarlo. Otro problema con esto es que se vuelve un poco tedioso convertir una clase en un módulo. El yo explícito está relacionado con el alcance limitado del que otros se han quejado. El alcance más pequeño en Python es el alcance de la función. Si mantiene sus funciones pequeñas, como debería, eso no es un problema en sí mismo y la OMI a menudo proporciona un código más limpio.

• Algunas funciones globales, como len, que esperarías que fuera un método (que en realidad está detrás de escena).

• Sangrado significativo. No es la idea en sí, lo que creo que es genial, pero dado que esto es lo único que impide que tanta gente pruebe Python, quizás Python estaría mejor con algunos símbolos de inicio / fin (opcionales). Ignorando a esas personas, también podría vivir totalmente con un tamaño forzado para la sangría.

• Que no es el lenguaje incorporado de los navegadores web, en lugar de JavaScript.

De estas quejas, es solo la primera que me importa lo suficiente y creo que debería agregarse al idioma. Los otros son bastante menores, excepto el último, ¡lo que sería genial si sucediera!

Python no está completamente maduro: el lenguaje python 3.2 en este momento tiene problemas de compatibilidad con la mayoría de los paquetes actualmente distribuidos (generalmente son compatibles con python 2.5). Este es un gran inconveniente que actualmente requiere más esfuerzo de desarrollo (encuentre el paquete necesario; verifique la compatibilidad; evalúe elegir un paquete que no sea tan bueno que pueda ser más compatible; tome la mejor versión, actualícela a 3.2, lo que podría llevar días; luego comenzar a hacer algo útil).

Probablemente a mediados de 2012 esto será un inconveniente menor.

Tenga en cuenta que supongo que un fan-boy me votó negativamente. Sin embargo, durante una discusión de desarrolladores, nuestro equipo de desarrolladores de alto nivel llegó a la misma conclusión.

La madurez en un sentido principal significa que un equipo puede usar la tecnología y ponerse en marcha muy rápidamente sin riesgos ocultos (incluidos los problemas de compatibilidad). Los paquetes de Python de terceros y muchas aplicaciones no funcionan en 3.2 para la mayoría de los paquetes de hoy. Esto crea más trabajo de integración, prueba, reimplementación de la tecnología en sí misma en lugar de resolver el problema en cuestión == tecnología menos madura.

Actualización para junio de 2013: Python 3 todavía tiene problemas de madurez. De vez en cuando, un miembro del equipo mencionará un paquete necesario y luego dirá "excepto que es solo para 2.6" (en algunos de estos casos he implementado una solución alternativa a través del socket localhost para usar el paquete solo 2.6 con 2.6, y el resto de nuestras herramientas se quedan con 3.2). Ni siquiera MoinMoin, el wiki de Python puro, está escrito en Python 3.

El alcance de Python está muy roto, lo que hace que la programación orientada a objetos en Python sea muy incómoda.

Mis quejas sobre Python:

• OOP atornillado (ver la respuesta de @ mipadi para más detalles sobre esto)
• Implementación rota de lambdas
• Problemas de alcance
• No hay colecciones persistentes en la biblioteca estándar.
• Poca susceptibilidad a las DSL integradas

Los modificadores de acceso en Python no son exigibles, lo que dificulta la escritura de código bien estructurado y modularizado.

Supongo que eso es parte del alcance roto de @ Mason, un gran problema en general con este lenguaje. Para el código que se supone que es legible, parece bastante difícil imaginar qué puede y debe estar dentro del alcance y qué valor tendrá en un momento dado: actualmente estoy pensando en pasar del lenguaje Python debido a estos inconvenientes. .

Solo porque "todos somos adultos con consentimiento" no significa que no cometamos errores y que no trabajemos mejor dentro de una estructura sólida, especialmente cuando trabajamos en proyectos complejos: la sangría y los subrayados sin sentido no parecen ser suficientes .

1. El rendimiento no es bueno, pero está mejorando con pypy,
2. El GIL evita el uso de subprocesos para acelerar el código (aunque esto suele ser una optimización prematura),
3. Solo es útil para la programación de aplicaciones,

Pero tiene algunas excelentes características de rescate:

1. Es perfecto para RAD,
2. Es fácil interactuar con C (y para que C incorpore un intérprete de Python),
3. Es muy legible
4. Es fácil de aprender
5. Está bien documentado
6. Las baterías realmente están incluidas, su biblioteca estándar es enorme y pypi contiene módulos para prácticamente todo,
7. Tiene una comunidad saludable.

Estoy a favor de Python y la primera desventaja que me viene a la mente es que cuando comento una declaración como if myTest():esta, debe cambiar la sangría de todo el bloque ejecutado que no tendría que ver con C o Java. De hecho, en Python, en lugar de comentar una cláusula if, comencé a comentarlo de esta manera: `if True: #myTest (), por lo que no tendré que cambiar el siguiente bloque de código. Como Java y C no dependen de la sangría, hace que comentar las declaraciones sea más fácil con C y Java.

El despacho múltiple no se integra bien con el sistema de tipo de despacho único establecido y no es muy eficiente.

La carga dinámica es un problema enorme en sistemas de archivos paralelos donde la semántica similar a POSIX conduce a ralentizaciones catastróficas para operaciones intensivas en metadatos. Tengo colegas que han quemado un cuarto de millón de horas centrales con solo cargar Python (con numpy, mpi4py, petsc4py y otros módulos de extensión) en 65k núcleos. (La simulación arrojó nuevos resultados científicos significativos, por lo que valió la pena, pero es un problema cuando se quema más de un barril de petróleo para cargar Python una vez). La incapacidad de vincular estáticamente nos ha obligado a ir a grandes contorsiones para tiempos de carga razonables a escala, incluyendo parchear libc-rtld para dlopenrealizar el acceso al sistema de archivos colectivo.

• un buen número de bibliotecas y software de terceros muy convencionales que son ampliamente utilizados, no son pitónicos. Algunos ejemplos: soaplib, openerp, reportlab. La crítica está fuera de alcance, está allí, se usa ampliamente, pero hace que la cultura de las pitones sea confusa (daña el lema que dice "Debería haber una, y preferiblemente solo una, forma obvia de hacerlo"). Los éxitos pitónicos conocidos (como django o trac) parecen ser la excepción.
• La profundidad de abstracción potencialmente ilimitada de instancia, clase, metaclase es conceptualmente hermosa y única. Pero para dominarlo, debe conocer profundamente al intérprete (en qué orden se interpreta el código de Python, etc.). No es ampliamente conocido y utilizado (o utilizado correctamente), mientras que la magia negra similar, como los genéricos de C #, que es conceptualmente más complicada (en mi humilde opinión) parece más conocida y utilizada, proporcionalmente.
• Para obtener una buena comprensión de la memoria y el modelo de subprocesos, debe tener bastante experiencia con Python, porque no hay especificaciones completas. Simplemente sabe lo que funciona, tal vez porque leyó las fuentes del intérprete o experimentó caprichos y descubrió cómo solucionarlos. Por ejemplo, solo hay referencias fuertes o débiles, no las referencias suaves y fantasmas de Java. Java tiene un hilo para la recolección de basura, mientras que no hay una respuesta formal sobre cuándo ocurre la recolección de basura en python; puede observar que la recolección de basura no ocurre si no se ejecuta ningún código de Python, y concluir que probablemente suceda a veces al intentar asignar memoria. Puede ser complicado cuando no sabes por qué no se lanzó un recurso bloqueado (mi experiencia al respecto fue mod_python en freeswitch).

De todos modos, Python es mi idioma principal desde hace 4 años. Ser fanboys, elitistas o monomaníacos no es parte de la cultura python.

• Extraña POO:
  • len(s)a través __len__(self)y otros "métodos especiales"
  • métodos extra especiales que podrían derivarse de otros métodos especiales ( __add__y __iadd__para +y +=)
  • self como primer parámetro del método
  • puedes olvidarte de llamar al constructor de la clase base
  • sin modificadores de acceso (privado, protegido ...)
• sin definiciones constantes
• sin inmutabilidad para tipos personalizados
• GIL
• bajo rendimiento que conduce a una mezcla de Python y C y problemas con las compilaciones (en busca de bibliotecas C, dependencias de la plataforma ...)
• mala documentación, especialmente en librerías de terceros
• incompatibilidad entre Python 2.xy 3.x
• herramientas de análisis de código deficientes (en comparación con lo que se ofrece para lenguajes tipados estáticamente como Java o C #)

"Inmutabilidad" no es exactamente su punto fuerte. Los números AFAIK, las tuplas y las cadenas son inmutables, todo lo demás (es decir, los objetos) es mutable. Compare eso con lenguajes funcionales como Erlang o Haskell, donde todo es inmutable (al menos por defecto).

Sin embargo, la inmutabilidad realmente brilla con la concurrencia *, que tampoco es el punto fuerte de Python, por lo que al menos es consecuente.

(* = Para los nitpickers: me refiero a la concurrencia que es al menos parcialmente paralela. Creo que Python está bien con la concurrencia de "subproceso único", en la que la inmutabilidad no es tan importante. (Sí, amantes de FP, sé que la inmutabilidad es genial incluso sin concurrencia.))

Me encantaría tener construcciones explícitamente paralelas. Más a menudo que no, cuando escribo una lista de comprensión como

[ f(x) for x in lots_of_sx ]

No me importa el orden en que se procesarán los elementos. A veces, ni siquiera me importa en qué orden se devuelven.

Incluso si CPython no puede hacerlo bien cuando mi f es Python puro, un comportamiento como este podría definirse para que otras implementaciones lo usen.

Python no tiene optimización de llamadas de cola, principalmente por razones filosóficas . Esto significa que el recursivo de cola en estructuras grandes puede costar memoria O (n) (debido a la pila innecesaria que se mantiene) y requerirá que reescriba la recursión como un bucle para obtener memoria O (1).