Quais são os principais pontos fracos de Python como linguagem de programação?

A essência das minhas queixas com Python resume-se a duas coisas:

• Muito da linguagem consiste em casos especiais em vez de características gerais que se combinam de formas ortogonais. Isto resulta em infelicidades e casos de cantos estranhos.
• Guido van Rossum tem um histórico de ter o design da linguagem realmente errado (por exemplo, http://neopythonic.blogspot.com/2009/04/tail-recursion-elimination.html), o que significa que podemos esperar que ele continue a ter coisas erradas no futuro.

alguns exemplos:

• >
• Python tem perpétua confusão de escopo. Tanto quanto eu posso dizer, isto é porque van Rossum não't entendeu inicialmente o escopo léxico, então ele entendeu errado. (Este é't um problema exclusivo de Python. Parece bastante comum entre as primeiras versões das linguagens de scripting). Originalmente, Python foi dinamicamente escopado, o que todos menos RMS concordam que está errado. Então eles eliminaram o escopo dinâmico, mas o fizeram de modo que os escopos internos não pudessem'nem mesmo ver variáveis dos escopos externos, o que é bizarro em uma linguagem supostamente estruturada em blocos. Agora os escopos internos podem ver escopos externos, mas podem't mude-os, o que é bizarro numa linguagem supostamente orientada a objetos. Alguns podem afirmar que isso é uma característica, mas isso'é um acidente de implementação. I'tenho certeza que quando ele consertar isso, ele'irá quebrar alguma outra coisa.
• David Parnaso inventou a informação escondida há mais de três décadas, mas ele's "unPythonic", então Python está faltando provavelmente o maior avanço na programação desde FORTRAN 2.
• eval breaks alpha-equivalence - isto é, você pode't arbitrariamente mudar os nomes das variáveis, porque algumas ocorrências de variáveis podem se esconder em strings, o que torna a estrutura de ligação do Python indecidível.
• Python não é digitado, o que significa que um monte de erros que são facilmente detectados antes do tempo são't detectados em Python até que eles aconteçam. Algumas pessoas gostam assim - e mais poder para elas! - mas vale sempre a pena considerar se é'é um erro para a sua aplicação em particular>li>Syntactic whitespace pode ser agradável, mas torna a geração de código mais difícil do que tem de ser. Este é't um problema difícil de resolver. Haskell permite que você use o espaço em branco sintático ou uma sintaxe equivalente envolvendo chaves e ponto-e-vírgula enrolados. Um é bom para as pessoas e o outro para a meta-programação, e aí'não há uma boa razão para não apoiar ambos. Não ajuda que quando as pessoas pedem isso, os implementadores do Python&apos têm sido muito ranhosos com isso. (Tente a partir de __future__ import braces.)li>Limitar os corpos de lambdas a serem expressões ao invés de declarações é arbitrário e irritante. Que declarações e atribuições de variáveis são expressões ao invés de expressões é arbitrária e irritante. A distinção declaração/expressão é arbitrária e irritante.
• "A [tabela hash] é uma estrutura de dados rígida". Python, como as outras linguagens baseadas em tabelas, encoraja você a usar "mapeamentos" para muitas coisas onde a soma dos produtos (algébricas) dos tipos de dados seria mais apropriada. Isto é ineficiente, mas mais importante ainda, é propenso a erros. Para continuar citando Perlis, "Os programadores não devem ser medidos pelo seu engenho e sua lógica, mas pela completude da sua análise de casos". A falta de suporte de Python's para estruturas de dados apropriadas encoraja a estrutura do programa que esconde a análise de casos. Correção: Andrew Cooke aponta que o chamado tuples (http://docs.python.org/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields) aborda parte deste problema.

Tudo o que foi dito, I'ainda prefere trabalhar com Python do que com PHP. Mas isso's é como dizer I'prefere comer Jack in the Box do que McDonald's. Pode ser um pouco mais palatável, mas ainda é muito ruim's.