Fazer muitas bibliotecas Python têm relativamente baixa qualidade do código?

Question

Editar: Uma vez que esta pergunta foi feita uma série de melhorias que aconteceu nas bibliotecas científicas Python padrão (que foi a área-alvo). Por exemplo, o projeto de numpy tem feito um grande esforço para melhorar as docstrings. Pode-se ainda discutem se teria sido possível resolver estas questões de forma contínua desde o início.

---

Eu tenho esta pergunta um pouco herege: Por que tantas bibliotecas Python têm código confuso e não seguem as melhores práticas padrão? Ou você acha que esta observação não é absolutamente verdadeiro? Como é que a situação em comparação com outras línguas? Estou interessado na sua opinião sobre isso.

Algumas razões pelas quais eu tenho a impressão de que a qualidade está faltando:

• Os docstrings são muitas vezes completamente ausente ou incompleta, mesmo para a API pública. É doloroso quando um método leva *args e **kwargs mas não documento que os valores podem ser dadas.

• Bad Python práticas de codificação, como a adição de novos atributos fora do __init__. Coisas como esta tornam o código difícil de ler (ou manter).

• Praticamente qualquer bibliotecas seguir o PEP8 convenções de codificação. Às vezes, as convenções não são ainda consistentes em um único arquivo.

• O projeto total é confuso, sem API clara. Parece que a refatoração não o suficiente é feito.

• Pobre cobertura unittest.

Não me entenda errado, Eu absolutamente amo Python e seu ecossistema . E mesmo que eu lutava com essas bibliotecas eles geralmente começar o trabalho feito e estou grato por isso . Mas também acho que no final toneladas de tempo desenvolvedor são desperdiçados por causa dessas questões. Talvez seja porque Python dá-lhe tanta liberdade que é muito fácil escrever código ruim .

Answer 1

documentação relativa, não é apenas Python. Se houver um único fator que está impedindo a adoção mais ampla de OSS é, IMHO, o nível verdadeiramente terrível da documentação da maioria dos projetos de OSS. Isso começa no nível de código e se estende até os documentos do usuário. Posso apenas dizer a qualquer um trabalho sobre OSS:

a) Comente seu código! Não existe tal coisa como código de auto documentar!

b) Passe pelo menos 25% do orçamento tempo de projeto na documentação do usuário final.

E eu sei vagamente o que eu estou falando - Eu tenho um par de projetos de OSS da minha própria, eu contribuiu para vários outros e eu usar OSS quase que exclusivamente. E ontem eu passei mais de 4 horas tentando construir um grande projeto OSS (nenhum nome, nenhuma perfuração pack), e não por causa da baixa qualidade, documentação de auto-contraditório.

Answer 2

Em vez disso, os autores cada parecem seguir a sua própria convenção gloriosa. E às vezes as convenções não são ainda consistentes com o mesmo arquivo de uma biblioteca

Bem-vindo ao código maravilhosa do mundo real!

código FWIW Python eu conheci não é melhor ou pior do que em qualquer outra língua.

(Bem, melhor do que o projeto médio PHP, obviamente, mas isso não é realmente justo.)

Answer 3

A primeira coisa que você precisa entender é que o Python não fez primavera, completamente formado, a partir da cabeça de Guido por volta versão 2.x. Tem crescido ao longo dos últimos vinte anos.

Na verdade, uma série de coisas que você menciona (unittest, por exemplo, e PEP-8), não existe mesmo quando algumas das bibliotecas padrão foram escritos em primeiro lugar.

Você provavelmente vai notar que quanto mais velha a biblioteca que você está olhando, o mais provável é que eles estão a ter divergências dos atuais "melhores práticas" - muitas vezes porque são anteriores a ampla adoção dessas práticas. bibliotecas mais recentes são mais propensos a estar em conformidade com as práticas correntes.

Além disso, por vezes, muitas vezes há uma boa razão para não trazê-los até à data. Imagine que você tem várias dezenas de milhares de linhas de código escrito contra as bibliotecas Python atuais. Agora, o mantenedor de uma dessas bibliotecas decide mudar as bibliotecas para tornar os nomes de classes e funções em conformidade com PEP-8. Agora todos que tem código de trabalho tem de revisitar grandes quantidades do mesmo, para que as coisas renomeação de quebra.

Isso não quer dizer que não são coisas que podem melhorar em bibliotecas Python - há! Mas há sempre um trade-off entre a perfeição e fazer as coisas. Essa é uma razão que eles dizem "Praticidade bate pureza."

Answer 4

Isto porque Python não é apoiada pelo mundo corporativo como Java ou .Net.

Se eu quero minha biblioteca Java para ser promovido pela Sun Vou seguir suas orientações. Este não é o caso com Python. Eu escrevo o meu código, as pessoas acham melhor e tem que evoluir por conta própria.

Além disso a maioria dos desenvolvedores do Python são de C ++, C, Java, .Net, etc. E eles começar a escrever direito código de produção desde o primeiro dia. Graças à facilidade de Python. E o ciclo vicioso continua.

Mesmo que me levou um mês para chegar a PEP8 e refatorar meu código.

Answer 5

PEP 8 mudou ao longo do tempo. Alguns módulos seguir as recomendações mais velhos. Você pode ver que com PIL, que utiliza módulos como "Imagem" onde o módulo contém uma única classe principal, ao invés do minúsculas recomendado para nomes de módulos, e em extensões C que usar o "c" prefixo, ao invés do mais moderno " _" prefixo.

Algumas das bibliotecas são desenvolvidos por pessoas que são fortemente influenciados pelas tradições em outros campos, como Java e C ++. Essas pessoas mais frequentemente usar CamelCase em vez dos lowercase_with_underscores PEP 8 recomendadas.

As respostas aqui não seria completa sem referência a Lei de Sturgeon : " noventa por cento de tudo é uma porcaria. "

Answer 6

Noventa por cento dos [bibliotecas python] são crud, mas noventa por cento de tudo é crud

- lei esturjões (parafraseado)

Answer 7

Parece que você têm vindo a descobrir que a qualidade do código não atende as expectativas que foram criadas para esperar. Talvez da escola, ou melhores livros de práticas ou desenvolvedores seniores.

Depois de ter trabalhado em várias empresas, encontrei-me regularmente aconselhados a fazer testes de unidade, código do documento, versão uso / controle de origem (todos os bons conselhos que tomei), em seguida, descobrir que os doadores de que o conselho raramente seguir o conselho si .

Eu diria que você tem a impressão de direita que às vezes a qualidade do código é baixo, mas apenas com base em suas expectativas. Certamente Numpy e outros são pacotes muito úteis, mesmo que não seja codificado para o padrão que foram criadas para esperar.

Os padrões são opiniões, e se você é da opinião de que os padrões são baixos, então você pode tentar para ajudar a tornar esses padrões melhor, contribuindo, ou aceitá-las como elas são e não se esqueça de escrever código que serve como um exemplo para os juniores você vai encontrar-se no comando de um dia.

Answer 8

Quanto matplotlib, há projeto para melhorá-lo de "pitonisa" - http://www.scipy.org/ Pylab

A coisa sobre bibliotecas científicas, é que eles são escritos pelo cientista, não por desenvolvedores de software profissionais. Moveover, os cientistas são usados ??para escrever Fortran. A questão é -? Você prefere ter código de trabalho ou código bela

Answer 9

PEP8 é um estilo guia , não uma exigência estilo. Ele ainda afirma que você deve "saber quando ser inconsistente". Pessoalmente, eu não gosto de algumas das orientações nela. Eu prefiro camelCase para snake_case desde que eu estou mais acostumado a isso.

E eu não muitas vezes olhar para o código-fonte das bibliotecas que estou usando a menos que seja absolutamente necessário (tais como depuração). Eu prefiro muito mais o documentação para a referida biblioteca a ser suficiente adequada que eu nunca tem que olhar para a fonte.

A sério, por que você realmente se importa o que o código-fonte para olhares matplotlib quiser, contanto que ele faz o que pretende fazer?

Eu concordo com você sobre o docstrings faltando (assumindo que eles são elementos públicos, em vez dos internos), mas isso não é a única maneira de documentar uma biblioteca.

Answer 10

Acredito que sofre Python de que está sendo içada demasiado avidamente em pessoas que não são programadores (por escolaridade ou comércio) como uma solução para "Precise alguma programação feito? Aqui, tente este fácil e ferramenta de amadurecer".

De forma semelhante à forma como PHP tornou-se um sucesso tão grande e com tantas bibliotecas com a qualidade do código abismal (mesmo se, concedido, a qualidade média código Python é melhor então para PHP) - o usuário médio PHP semelhante para o usuário médio Python tem não muita experiência de programação ou habilidades e muito pouco incentivo para melhorar a si mesmos a este respeito - eles partiram para alcançar algo, e talvez eles pensaram que é suficiente digna de ser compartilhada com a comunidade na forma de uma biblioteca, mas na maioria das vezes uma vez que o trabalho é feito eles não têm interesse para melhor o código ou melhor a si mesmos (em habilidades de programação, quero dizer).

A solução pode ser para repositórios biblioteca Python (como PyPI) ter regras mais estritas sobre a aceitação de pacotes contribuíram - lidar com isso com um processo de revisão, cujo objetivo é garantir a qualidade - da mesma forma que as principais distribuições Linux têm um processo de revisão antes a adição de um pacote para seus repositórios.

Answer 11

PEP8 é apenas isso, uma convenção, não uma exigência. Seria muito triste se todos os programadores python estiveste para aderir a um conjunto comum de regras, nós entusiasmo perder mais a menor de questões.

Quanto docstrings desaparecidas estão preocupados - sim, eles podem ajudar ao usar a ajuda interativa - mas eu geralmente não me importo, desde que há alguns documentação. Eu tento não ler o código fonte das bibliotecas que eu uso, eu tendem a começar a modificar (reescrevendo)-los.

Answer 12

No que diz respeito comparação com outras línguas, eu acho que o design linguagem desempenha um papel importante aqui. Por exemplo, em uma linguagem forte-digitada como Java, mesmo se a biblioteca está faltando documentação boa, você ainda pode deduzir grande parte da funcionalidade das assinaturas de método. Sem *args de enfrentar.

Answer 13

Como sobre uma coleção de exemplos de boas doc software?
Bons exemplos podem levar à melhoria global um pouco mais rápido do que passeio aleatório.
A coleção pode ser dividida em categorias, tais como:
página doc / help em linha / tutorial Manual / referência, página web / papel, fotos / nenhum.
Cada entrada deve ter algumas palavras sobre por os achados colaborador é bom.
(Onde:? Um canto do stackoverflow)

Answer 14

nikow: Eu só posso responder por mim mesmo, a maioria do meu Python (e PHP ou Ruby, todas as dinâmicas "script" línguas) o trabalho é feito apenas para me - mas eu sempre liberá-lo no meu site pessoal se alguém acha útil, mas eu nunca passar por qualquer documentação ou processo de QA, porque enquanto ele trabalha para mim, estou feliz.

Answer 15

Bem, eles são de código aberto. Como tal, eles também irá evoluir ao longo do tempo, se eles são bons o suficiente.

Essa é uma das muitas belezas de código aberto.

Muitas vezes, há pouco sentido em escrever monte de documentação e código "bom" se você não sabe se o projeto vai viver. Isso seria um desperdício de tempo.

Edit: Claro que escrever código bom nunca machucaria a primeira vez embora ... Mas talvez apenas "fazer o trabalho" é bom o suficiente em muitos casos. Eu acho que de outra forma não iria desfrutar da vasta quantidade de opções quando se trata de OSS.

Eu acho que se as pessoas o suficiente agir de forma específica, pode haver alguma explicação para isso. Eles não estão apenas fazendo aleatoriamente de modo a ofendê-lo.

Answer 16

Qualidade de código * número de comentários * tempo = constante

Escolha dois!

Eu nunca tive qualquer problema com matplotlib; Não posso dizer que olhou para o código muito - é uma biblioteca bem. Faz o que é suposto fazer (de graça!)