Quais são as desvantagens do Python? [fechadas]

Atualmente, o Python parece estar com toda a raiva, e não é merecedor de elogios - pois é realmente uma linguagem com a qual quase se gosta de receber um novo problema para resolver. Mas, como um homem sábio disse uma vez (chamando-o de homem sábio apenas porque não tenho idéia de quem realmente disse isso; não tenho certeza se ele era tão sábio), para realmente conhecer uma língua, não se sabe apenas sua sintaxe, design, etc., vantagens, mas também suas desvantagens. Nenhuma linguagem é perfeita, algumas são melhores que outras.

Então, o que seria, na sua opinião, desvantagens objetivas do Python.

Nota: Eu não estou pedindo uma comparação de idiomas aqui (por exemplo, C # é melhor que Python porque ... yadda yadda yadda) - mais uma opinião objetiva (em algum nível) sobre quais recursos de linguagem foram mal projetados, se, quais são talvez alguns estão faltando nele e assim por diante. Se deve usar outro idioma como comparação, mas apenas para ilustrar um ponto que seria difícil de elaborar de outra maneira (isto é, para facilitar o entendimento)

Eu uso o Python com alguma regularidade e, no geral, considero uma linguagem muito boa. No entanto, nenhuma linguagem é perfeita. Aqui estão as desvantagens em ordem de importância para mim pessoalmente:

1. É lento. Quero dizer muito, muito devagar. Muitas vezes isso não importa, mas definitivamente significa que você precisará de outro idioma para esses bits críticos de desempenho.

2. Funções aninhadas meio que sugam que você não pode modificar variáveis ​​no escopo externo. Edit: Eu ainda uso o Python 2 devido ao suporte da biblioteca, e essa falha de design me irrita, mas aparentemente ele foi corrigido no Python 3 devido à declaração não - local . Mal posso esperar para que as bibliotecas que eu uso sejam portadas, para que essa falha possa ser enviada para o monte de cinzas da história para sempre.

3. Faltam alguns recursos que podem ser úteis para a biblioteca / código genérico e o IMHO é a simplicidade levada a extremos prejudiciais. Os mais importantes que consigo pensar são os tipos de valores definidos pelo usuário (acho que eles podem ser criados com a metaclasse mágica, mas nunca tentei) e o parâmetro da função ref.

4. Está longe do metal. Precisa escrever primitivas de encadeamento ou código do kernel ou algo assim? Boa sorte.

5. Embora eu não me importe com a falta de capacidade de capturar erros semânticos antecipadamente como uma compensação pelo dinamismo que o Python oferece, gostaria que houvesse uma maneira de capturar erros sintáticos e coisas bobas, como digitar nomes de variáveis ​​sem precisar executar o código.

6. A documentação não é tão boa quanto linguagens como PHP e Java que têm fortes bases corporativas.

Odeio que o Python não consiga distinguir entre declaração e uso de uma variável. Você não precisa de digitação estática para fazer isso acontecer. Seria bom ter uma maneira de dizer "essa é uma variável que deliberadamente declaro e pretendo introduzir um novo nome, isso não é um erro de digitação".

Além disso, eu costumo usar variáveis ​​Python em um estilo de gravação única, ou seja, trato as variáveis ​​como imutáveis ​​e não as modifico após a primeira atribuição. Graças a recursos como compreensão de lista, isso é incrivelmente fácil e facilita o acompanhamento do código.

No entanto, não posso documentar esse fato. Nada no Python me impede de substituir ou reutilizar variáveis.

Em resumo, eu gostaria de ter duas palavras-chave no idioma: vare let. Se eu escrever em uma variável não declarada por nenhuma delas, o Python deve gerar um erro. Além disso, letdeclara variáveis ​​como somente leitura, enquanto varvariáveis ​​são "normais".

Considere este exemplo:

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

Observe que os tipos ainda estão implícitos (mas as letvariáveis ​​são digitadas estaticamente para todos os efeitos, pois não podem ser recuperadas para um novo valor, enquanto as varvariáveis ​​ainda podem ser digitadas dinamicamente).

Finalmente, todos os argumentos do método devem ser automaticamente let, ou seja, devem ser somente leitura. Geralmente, não há bons motivos para modificar um parâmetro, exceto pelo seguinte idioma:

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

Isso pode ser substituído por um idioma ligeiramente diferente:

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

Minha principal reclamação é o threading, que não é tão eficiente em muitas circunstâncias (em comparação com Java, C e outras) devido ao bloqueio global de intérpretes (consulte a palestra "Inside the Python GIL" (link em PDF) )

No entanto, há uma interface de multiprocessos muito fácil de usar, mas será mais pesada no uso de memória para o mesmo número de processos versus threads, ou difícil se você tiver muitos dados compartilhados. O benefício, no entanto, é que, quando você tem um programa trabalhando com vários processos, ele pode ser escalonado em várias máquinas, algo que um programa encadeado não pode fazer.

Eu realmente discordo da crítica da documentação, acho que é excelente e melhor do que a maioria, se não todas as principais línguas existentes.

Além disso, você pode capturar muitos dos erros de tempo de execução executando o pylint .

Indiscutivelmente , a falta de digitação estática, que pode introduzir certas classes de erros de tempo de execução , não vale a flexibilidade adicional oferecida pela digitação de pato.

Eu acho que as partes orientadas a objetos do Python parecem "apertadas". Toda a necessidade de passar explicitamente o "eu" para todo método é um sintoma de que seu componente OOP não foi expressamente planejado , você poderia dizer; também mostra as regras de escopo às vezes vergonhosas do Python que foram criticadas em outra resposta.

Editar:

Quando digo que as partes orientadas a objetos do Python parecem "aparafusadas", quero dizer que, às vezes, o lado da OOP parece bastante inconsistente. Veja o Ruby, por exemplo: no Ruby, tudo é um objeto e você chama um método usando a obj.methodsintaxe familiar (com exceção dos operadores sobrecarregados, é claro); no Python, tudo também é um objeto, mas alguns métodos você chama como função; ou seja, você sobrecarrega __len__para retornar um comprimento, mas chame-o usando, em len(obj)vez do mais familiar (e consistente) obj.lengthcomum em outros idiomas. Sei que há razões por trás dessa decisão de design, mas não gosto delas.

Além disso, o modelo OOP do Python não possui nenhum tipo de proteção de dados, ou seja, não há membros privados, protegidos e públicos; você pode imitá-los usando _e __na frente dos métodos, mas é meio feio. Da mesma forma, o Python também não entende bem o aspecto de passagem de mensagens do OOP.

Coisas que não gosto no Python:

1. Threading (eu sei que já foi mencionado, mas vale a pena mencionar em todos os posts).
2. Não há suporte para funções anônimas de várias linhas ( lambdapode conter apenas uma expressão).
3. A falta de uma simples, mas poderosa função de leitura de entrada / classe (como cinou scanfem C ++ e C ou Scannerem Java).
4. Todas as strings não são unicode por padrão (mas corrigidas no Python 3).

Argumentos padrão com tipos de dados mutáveis.

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

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

Geralmente é o resultado de alguns erros sutis. Eu acho que seria melhor se ele criasse um novo objeto de lista sempre que um argumento padrão fosse necessário (em vez de criar um único objeto para usar em todas as chamadas de função).

Editar: não é um problema enorme, mas quando algo precisa ser referido nos documentos, geralmente significa que é um problema. Isso não deve ser necessário.

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

Especialmente quando esse deveria ter sido o padrão. É apenas um comportamento estranho que não corresponde ao que você esperaria e não é útil para um grande número de circunstâncias.

Alguns dos recursos do Python que o tornam tão flexível como uma linguagem de desenvolvimento também são vistos como grandes desvantagens daqueles usados ​​na análise estática do "programa inteiro", conduzida pelo processo de compilação e vinculação em linguagens como C ++ e Java.

• Declaração implícita de variáveis ​​locais

Variáveis ​​locais são declaradas usando a declaração de atribuição comum. Isso significa que as ligações variáveis ​​em qualquer outro escopo exigem que a anotação explícita seja captada pelo compilador (declarações globais e não locais para escopos externos, notação de acesso a atributos para escopos de instância). Isso reduz enormemente a quantidade de clichê necessária durante a programação, mas significa que são necessárias ferramentas de análise estática de terceiros (como pyflakes) para executar verificações tratadas pelo compilador em linguagens que exigem declarações explícitas de variáveis.

• "Monkey patching" é suportado

O conteúdo dos módulos, objetos de classe e até o espaço para nome interno pode ser modificado em tempo de execução. Isso é extremamente poderoso, permitindo muitas técnicas extremamente úteis. No entanto, essa flexibilidade significa que o Python não oferece alguns recursos comuns às linguagens OO de tipo estatístico. Mais notavelmente, o parâmetro "self" para métodos de instância é explícito e não implícito (como "métodos" não precisam ser definidos dentro de uma classe, eles podem ser adicionados posteriormente modificando a classe, o que significa que não é particularmente prático para passar a referência da instância implicitamente) e os controles de acesso ao atributo não podem ser facilmente aplicados com base no fato de o código estar "dentro" ou "fora" da classe (pois essa distinção existe apenas enquanto a definição da classe está sendo executada).

• Longe do metal

Isso também se aplica a muitas outras linguagens de alto nível, mas o Python tende a abstrair a maioria dos detalhes de hardware. Linguagens de programação de sistemas como C e C ++ ainda são muito mais adequadas para lidar com o acesso direto ao hardware (no entanto, o Python conversará alegremente com aqueles por meio dos módulos de extensão CPython ou, de maneira mais portável, pela ctypesbiblioteca).

1. Usando indentação para blocos de código em vez de {} / begin-end, qualquer que seja.
2. Toda linguagem moderna mais recente tem escopo lexical adequado, mas não o Python (veja abaixo).
3. Documentos caóticos (compare com a documentação do Perl5, que é excelente).
4. Camisa de força (há apenas uma maneira de fazê-lo).

Exemplo para escopo quebrado; transcrição da sessão do 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

globale nonlocalpalavras - chave foram introduzidas para corrigir essa estupidez de design.

Acho a combinação de sintaxe orientada a objetos this.method()e procedural / funcional do python method(this)muito perturbadora:

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

Isso é particularmente ruim porque um grande número de funções (em vez de métodos) é apenas despejado no espaço de nomes global : métodos relacionados a listas, seqüências de caracteres, números, construtores, metaprogramação, todos misturados em uma grande lista alfabética.

No mínimo, linguagens funcionais como o F # têm todas as funções devidamente nomeadas em módulos:

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

Então eles não estão todos juntos. Além disso, esse é um padrão seguido em toda a biblioteca, pelo menos é consistente.

Eu entendo as razões para fazer a função vs coisa de método , mas ainda acho que é uma má idéia para misturá-los assim. Eu ficaria muito mais feliz se a sintaxe do método fosse seguida, pelo menos para as operações comuns:

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

Se os métodos estão mudando ou não, tê-los como métodos no objeto tem várias vantagens:

• Local único para procurar as operações "comuns" em um tipo de dados: outras bibliotecas / etc. podem ter outras coisas sofisticadas que podem fazer com os tipos de dados, mas as operações "padrão" estão nos métodos do objeto.
• Não é necessário continuar repetindo a Modulechamada Module.method(x). Tomando o exemplo funcional da lista acima, por que tenho que continuar dizendo Listrepetidamente? Deve saber que é um Liste não quero chamar a Navigation.map()função! O uso da x.map()sintaxe a mantém SECA e ainda não ambígua.

E, é claro, tem vantagens em relação à maneira de colocar tudo no espaço de nomes global . Não é que a maneira atual seja incapaz de fazer as coisas. É até bem conciso ( len(lst)), já que nada está no namespace! Entendo as vantagens de usar funções (comportamento padrão, etc.) sobre métodos, mas ainda não gosto.

É apenas bagunçado. E em grandes projetos, a bagunça é seu pior inimigo.

Falta de homoiconicidade .

O Python teve que esperar pelo 3.x para adicionar uma palavra-chave "with". Em qualquer idioma homoicônico, poderia ter sido adicionado trivialmente em uma biblioteca.

A maioria dos outros problemas que vi nas respostas são de um dos três tipos:

1) Coisas que podem ser corrigidas com ferramentas (por exemplo, pyflakes) 2) Detalhes da implementação (GIL, desempenho) 3) Coisas que podem ser corrigidas com padrões de codificação (ou seja, recursos que as pessoas desejam que não existam)

# 2 não é um problema com o idioma, IMO # 1 e # 3 não são problemas sérios.

Python é minha linguagem favorita, pois é muito expressiva, mas ainda evita que você cometa muitos erros. Eu ainda tenho algumas coisas que me incomodam:

• Nenhuma função anônima real. O Lambda pode ser usado para funções de instrução única, e a withinstrução pode ser usada para muitas coisas em que você usaria um bloco de código no Ruby. Mas, em algumas situações, as coisas ficam um pouco mais desajeitadas do que teriam que ser. (Longe de ser tão desajeitado quanto seria em Java, mas ainda assim ...)

• Alguma confusão na relação entre módulos e arquivos. A execução de "python foo.py" na linha de comando é diferente de "import foo". As importações relativas no Python 2.x também podem causar problemas. Ainda assim, os módulos do Python são muito melhores que os recursos correspondentes de C, C ++ e Ruby.

• Explícito self. Embora eu entenda algumas das razões para isso, e mesmo que eu use o Python diariamente, eu cometo o erro de esquecê-lo. Outro problema é que se torna um pouco entediante transformar uma classe em um módulo. O eu explícito está relacionado ao escopo limitado do qual os outros se queixaram. O menor escopo no Python é o escopo da função. Se você mantiver suas funções pequenas, como deveria, isso não será um problema por si só e o IMO geralmente fornecerá um código mais limpo.

• Algumas funções globais, como len, que você esperaria ser um método (que na verdade é nos bastidores).

• Recuo significativo. Não é a ideia em si, que eu acho ótima, mas como essa é a única coisa que impede tantas pessoas de experimentar o Python, talvez o Python seja melhor com alguns símbolos de início / fim (opcionais). Ignorando essas pessoas, eu também poderia viver totalmente com um tamanho obrigatório para o recuo.

• Que não é o idioma interno dos navegadores da web, em vez do JavaScript.

Dessas reclamações, é apenas a primeira com a qual me preocupo o suficiente, e acho que deve ser adicionada ao idioma. Os outros são bem menores, exceto o último, o que seria ótimo se isso acontecesse!

O Python não está totalmente maduro: a linguagem do python 3.2 atualmente tem problemas de compatibilidade com a maioria dos pacotes atualmente distribuídos (normalmente eles são compatíveis com o python 2.5). Essa é uma grande desvantagem que atualmente exige mais esforço de desenvolvimento (encontre o pacote necessário; verifique a compatibilidade; pese escolhendo um pacote não tão bom que possa ser mais compatível; obtenha a melhor versão, atualize-a para 3,2, o que pode levar dias; comece a fazer algo útil).

Provavelmente, em meados de 2012, isso será menos uma desvantagem.

Note que eu acho que fui votado por um fã-boy. Durante uma discussão com desenvolvedores, nossa equipe de desenvolvedores de alto nível chegou à mesma conclusão.

A maturidade, em um sentido principal, significa que uma equipe pode usar a tecnologia e estar em funcionamento muito rapidamente, sem riscos ocultos (incluindo problemas de compatibilidade). Pacotes python de terceiros e muitos aplicativos não funcionam na versão 3.2 para a maioria dos pacotes hoje. Isso cria mais trabalho de integração, teste, reimplementação da própria tecnologia, em vez de resolver o problema em questão == tecnologia menos madura.

Atualização para junho de 2013: Python 3 ainda tem problemas de maturidade. De vez em quando, um membro da equipe menciona um pacote necessário e diz "exceto que é apenas para 2.6" (em alguns desses casos, eu implementei uma solução alternativa via soquete localhost para usar o pacote somente para 2.6 com 2.6 e o ​​restante de nossas ferramentas ficam com 3.2). Nem o MoinMoin, o wiki em python puro, é escrito em Python 3.

O escopo do Python está muito quebrado, o que torna a programação orientada a objetos no Python muito estranha.

Minhas queixas sobre Python:

• OOP aparafusado (Veja a resposta de @ mipadi para elaboração deste)
• Implementação interrompida de lambdas
• Questões de escopo
• Nenhuma coleção persistente na biblioteca padrão
• Má acessibilidade a DSLs incorporadas

Os modificadores de acesso no Python não são aplicáveis ​​- dificultam a criação de códigos modularizados e bem estruturados.

Suponho que isso faça parte do escopo quebrado da @ Mason - um grande problema em geral com esse idioma. Para o código que deveria ser legível, parece bastante difícil descobrir o que pode e deve estar no escopo e qual será o valor em um determinado momento - atualmente, estou pensando em mudar da linguagem Python por causa desses inconvenientes. .

Só porque "todos nós somos adultos concordantes" não significa que não cometemos erros e não trabalhemos melhor dentro de uma estrutura sólida, especialmente quando se trabalha em projetos complexos - indentação e sublinhados sem sentido não parecem suficientes .

1. O desempenho não é bom, mas está melhorando com o pypy,
2. O GIL impede o uso de threading para acelerar o código (embora isso geralmente seja uma otimização prematura),
3. Só é útil para programação de aplicativos,

Mas tem alguns ótimos recursos redentores:

1. É perfeito para a RAD,
2. É fácil interagir com C (e para C incorporar um intérprete python),
3. É muito legível,
4. É fácil aprender,
5. Está bem documentado,
6. As baterias estão realmente incluídas, sua biblioteca padrão é enorme e o pypi contém módulos para praticamente tudo,
7. Tem uma comunidade saudável.

Eu sou a favor do python e a primeira desvantagem que me vem à cabeça é que, ao comentar uma declaração como essa if myTest():, você deve alterar a indentação de todo o bloco executado que você não teria a ver com C ou Java. De fato, em python, em vez de comentar uma cláusula if, comecei a comentá-la desta maneira: `if True: #myTest (), portanto não precisarei alterar o seguinte bloco de código. Como Java e C não contam com indentação, torna mais fácil comentar declarações com C e Java.

O despacho múltiplo não se integra bem ao sistema do tipo de despacho único estabelecido e não tem muito desempenho.

O carregamento dinâmico é um grande problema em sistemas de arquivos paralelos em que a semântica do tipo POSIX leva a lentidão catastrófica para operações com uso intenso de metadados. Tenho colegas que gastaram um quarto de milhão de horas-núcleo apenas carregando o Python (com numpy, mpi4py, petsc4py e outros módulos de extensão) carregados em núcleos de 65k. (A simulação produziu resultados científicos novos e significativos, por isso valeu a pena, mas é um problema quando mais de um barril de petróleo é queimado para carregar o Python uma vez.) A incapacidade de vincular estaticamente nos forçou a fazer grandes contorções para obter tempos de carregamento razoáveis ​​em escala, incluindo o patch libc-rtld para fazer o dlopenacesso coletivo ao sistema de arquivos.

• um monte de bibliotecas e softwares de terceiros muito populares que são amplamente utilizados, não são pitonicos. Alguns exemplos: soaplib, openerp, reportlab. A crítica está fora do escopo, está lá, é amplamente usada, mas torna a cultura python confusa (prejudica o lema que diz: "Deveria haver uma - e de preferência apenas uma - maneira óbvia de fazê-lo"). Sucessos pitônicos conhecidos (como django ou trac) parecem ser a exceção.
• a profundidade potencialmente ilimitada da abstração da instância, classe, metaclasse é conceitualmente bonita e única. Mas para dominá-lo, você precisa conhecer profundamente o intérprete (em que ordem o código python é interpretado etc.). Não é amplamente conhecido e usado (ou usado corretamente), enquanto magia negra semelhante, como os genéricos C #, conceitualmente mais complicada (IMHO) parece mais amplamente conhecida e usada proporcionalmente.
• Para obter uma boa compreensão do modelo de memória e de encadeamento, é necessário ter bastante experiência com python, porque não há especificações abrangentes. Você apenas sabe o que funciona, talvez porque você leu as fontes do intérprete ou peculiaridades experientes e descobriu como corrigi-las. Por exemplo, existem apenas referências fortes ou fracas, não as referências suaves e fantasmas do java. Java possui um encadeamento para coleta de lixo, enquanto não há resposta formal sobre quando a coleta de lixo ocorre em python; você pode apenas observar que a coleta de lixo não ocorre se nenhum código python for executado e concluir que provavelmente está acontecendo algumas vezes ao tentar alocar memória. Pode ser complicado quando você não sabe por que um recurso bloqueado não foi lançado (minha experiência sobre isso foi mod_python no freeswitch).

De qualquer forma, python é minha língua principal há 4 anos. Ser fanboys, elitistas ou monomaníacos não faz parte da cultura python.

• OOP estranho:
  • len(s)através __len__(self)e outros "métodos especiais"
  • métodos especiais extras que podem ser derivados de outros métodos especiais ( __add__e __iadd__para +e +=)
  • self como primeiro parâmetro do método
  • você pode esquecer de chamar o construtor da classe base
  • sem modificadores de acesso (privado, protegido ...)
• sem definições constantes
• sem imutabilidade para tipos personalizados
• GIL
• baixo desempenho que leva a uma mistura de Python e C e problemas com as compilações (procurando bibliotecas C, dependências de plataforma ...)
• documentação ruim, especialmente em bibliotecas de terceiros
• incompatibilidade entre Python 2.xe 3.x
• ferramentas de análise de código ruins (em comparação com o que é oferecido para linguagens estaticamente tipadas, como Java ou C #)

"Imutabilidade" não é exatamente o ponto forte. Os números, tuplas e cordas AFAIK são imutáveis, todo o resto (ou seja, objetos) é mutável. Compare isso com linguagens funcionais como Erlang ou Haskell, onde tudo é imutável (por padrão, pelo menos).

No entanto, a imutabilidade realmente brilha com a simultaneidade *, que também não é o ponto forte do Python, pelo menos é consequente.

(* = Para os nitpickers: quero dizer simultaneidade que é pelo menos parcialmente paralela. Acho que o Python está bem com simultaneidade "single-threaded", na qual a imutabilidade não é tão importante. (Sim, amantes de FP, eu sei que a imutabilidade é ótimo mesmo sem simultaneidade.))

Eu adoraria ter construções explicitamente paralelas. Frequentemente, quando escrevo uma lista de compreensão como

[ f(x) for x in lots_of_sx ]

Não ligo para a ordem em que os elementos serão processados. Às vezes, eu nem me importo com a ordem em que elas são devolvidas.

Mesmo que o CPython não possa fazê-lo bem quando meu f é puro Python, um comportamento como esse pode ser definido para outras implementações usarem.

O Python não possui otimização de chamada de cauda, ​​principalmente por razões filosóficas . Isso significa que a recursão final em estruturas grandes pode custar memória O (n) (devido à pilha desnecessária mantida) e exigirá que você reescreva a recursão como um loop para obter memória O (1).