Многие ли библиотеки Python имеют относительно низкое качество кода?

Question

Редактировать: С тех пор, как был задан этот вопрос, в стандартных научных библиотеках Python (которые были целевой областью) произошло значительное улучшение. Например, проект numpy приложил большие усилия для улучшения строк документации. Можно до сих пор спорить, можно ли было бы постоянно решать эти проблемы с самого начала.

---

У меня такой несколько еретический вопрос: почему так много библиотек Python имеют грязный код и не следуют стандартным рекомендациям? Или вы думаете, что это наблюдение абсолютно не соответствует действительности? Как ситуация сравнивается с другими языками? Мне интересно ваше мнение об этом.

Некоторые причины, по которым у меня сложилось впечатление, что качество не хватает:

• Строки документации часто полностью отсутствуют или неполны, даже для общедоступного API. Больно, когда метод принимает *args и **kwargs, но не документирует, какие значения могут быть заданы.

• Плохие практики кодирования Python, такие как добавление новых атрибутов за пределы __init__. Подобные вещи делают код трудным для чтения (или сопровождения).

• Вряд ли какие-либо библиотеки следуют правилам кодирования PEP8. Иногда соглашения даже не согласованы в одном файле.

• Общий дизайн грязный, без чёткого API. Похоже, что рефакторинг выполнен недостаточно.

• Плохое покрытие юнит тестов.

Не поймите меня неправильно, Я очень люблю Python и его экосистему . И хотя я боролся с этими библиотеками , они обычно выполняют свою работу, и я благодарен за это . Но я также думаю, что в итоге из-за этих проблем теряется время разработчиков. Возможно, это из-за того, что Python дает вам такую ​​свободу, что очень просто написать плохой код .

Answer 1

Что касается документации, это не просто Python. Если существует один единственный фактор, препятствующий более широкому внедрению OSS, то это, IMHO, действительно ужасный уровень документации большинства проектов OSS. Это начинается на уровне кода и распространяется на пользовательские документы. Могу ли я просто сказать всем, кто работает над OSS:

а) Прокомментируйте свой код! Самодокументируемого кода не существует!

b) Потратить не менее 25% бюджета времени проекта на документацию для конечного пользователя.

И я смутно знаю, о чем говорю - у меня есть несколько моих собственных проектов OSS, я участвовал в нескольких других, и я использую OSS почти исключительно. А вчера я потратил более 4 часов, пытаясь создать крупный проект OSS (без имен, без пакетного обучения), и потерпел неудачу из-за дурацкой, противоречивой документации.

Answer 2

Первое, что вам нужно осознать, это то, что Python не возник полностью сформированным из головы Гвидо, когда-то около версии 2.x. Он вырос за последние двадцать лет.

На самом деле, ряд вещей, о которых вы упомянули (например, unittest и PEP-8), даже не существовал, когда некоторые стандартные библиотеки были впервые написаны.

Вы, вероятно, заметите, что чем старше библиотека, на которую вы смотрите, тем больше вероятность того, что они будут расходиться с текущими "передовыми методами" - часто потому, что они предшествуют широкому распространению этих практик. Более поздние библиотеки с большей вероятностью соответствуют существующим практикам.

Кроме того, иногда есть веская причина для , а не для их обновления. Представьте, что у вас есть несколько десятков тысяч строк кода, написанных для текущих библиотек Python. Теперь сопровождающий одной из этих библиотек решает изменить библиотеки, чтобы имена классов и функций соответствовали PEP-8. Теперь каждый, у кого есть рабочий код, должен пересмотреть его огромное количество, чтобы не переименовывать перерыв.

Это не значит, что в библиотеках Python нет вещей, которые можно улучшить - они есть! Но всегда есть компромисс между совершенством и достижением цели. Это одна из причин, по которой они говорят: «Практичность побеждает чистоту».

Answer 3

Вместо этого каждый из авторов, похоже, следует своим собственным славным правилам. И иногда соглашения даже не соответствуют одному и тому же файлу библиотеки

Добро пожаловать в замечательный код реального мира!

Код FWIW Python, с которым я встречался, ничем не лучше и не хуже, чем на любом другом языке.

(Ну, конечно, лучше, чем обычный проект PHP, но это не совсем справедливо.)

Answer 4

PEP 8 со временем изменился. Некоторые модули следуют более старым рекомендациям. Вы можете видеть это с PIL, который использует такие модули, как «Image», где модуль содержит один основной класс вместо рекомендованного нижнего регистра для имен модулей, и в расширениях C, которые используют префикс «c» вместо более современного _ "префикс.

Некоторые библиотеки разрабатываются людьми, которые находятся под сильным влиянием традиций в других областях, таких как Java и C ++. Эти люди чаще используют CamelCase вместо рекомендованного PEP 8 lowercase_with_underscores.

Ответы здесь не будут полными без ссылки на Закон осетровых : «Девяносто процентов всего дерьма».

Answer 5

Это потому, что Python не поддерживается корпоративным миром, таким как Java или .Net.

Если я хочу, чтобы моя библиотека Java поддерживалась Sun, я буду следовать их указаниям. Это не так с Python. Я пишу свой код, люди находят его лучше, и он должен развиваться сам по себе.

Также большинство разработчиков Python из C ++, C, Java, .Net и т. Д. И они начинают писать рабочий код с первого дня. Благодаря легкости Python. И порочный круг продолжается.

Даже мне потребовался месяц, чтобы прийти к PEP8 и провести рефакторинг моего кода.

Answer 6

Звучит так, как будто вы пришли к выводу, что качество кода не соответствует ожиданиям, на которые вы рассчитывали. Возможно, из школы, или из книг о лучших практиках, или у старших разработчиков.

После работы в нескольких компаниях я регулярно советовал проводить модульные тесты, документировать код, использовать контроль версий / исходного кода (все полезные советы, которые я принял), а затем обнаружил, что исполнители этого совета редко следуют этим советам ,

Я бы сказал, что у вас сложилось правильное впечатление, что иногда качество кода низкое, но только исходя из ваших ожиданий. Конечно, numpy и другие - довольно полезные пакеты, даже если они не соответствуют стандарту, который вы ожидали.

Стандарты - это мнения, и если вы считаете, что стандарты низкие, то вы можете попытаться помочь улучшить эти стандарты, предоставив или приняв их такими, какие они есть, и обязательно напишите код, который служит примером для юниоры вы будете отвечать за один день.

Answer 7

Девяносто процентов [библиотек Python] не соответствуют друг другу, но девяносто процентов всего не имеют

- Право осетровых (перефразировано)

Answer 8

Что касается matplotlib, то есть проект по улучшению его "pythoness" - http://www.scipy.org/PyLab

Суть научных библиотек в том, что они написаны учеными, а не профессиональными разработчиками программного обеспечения. Moveover, эти ученые используются для написания Фортрана. Вопрос - вы бы предпочли рабочий код или красивый код?

Answer 9

PEP8 - это руководство по стилю , а не требование к стилю. В нем даже говорится, что вы должны «знать, когда нужно быть непоследовательным». Лично мне не нравятся некоторые из руководящих принципов в этом. Я предпочитаю от camelCase до snake_case, так как я более привык к этому.

И я не часто смотрю на исходный код библиотек, которые я использую, за исключением случаев, когда это абсолютно необходимо (например, отладка). Я бы предпочел, чтобы документация для указанной библиотеки была достаточной, чтобы мне никогда не приходилось смотреть на источник.

Серьезно, почему вас действительно волнует, как выглядит исходный код для matplotlib, если он делает то, для чего предназначен?

Я согласен с вами по поводу отсутствующего docstrings (при условии, что это открытые элементы, а не внутренние), но это не единственный способ документировать библиотеку.

Answer 10

Я полагаю, что Python страдает от того, что его слишком охотно привлекают люди, которые не являются программистами (в школе или в сфере торговли), в качестве решения "нужно ли программирование закончено? Здесь, попробуйте этот простой и зрелый инструмент".

Подобно тому, как PHP стал таким огромным успехом и с таким большим количеством библиотек с ужасным качеством кода (даже если, конечно, среднее качество кода Python лучше, чем для PHP) - средний пользователь PHP, как и обычный пользователь Python, имеет не много опыта или навыков программирования и очень мало стимулов для улучшения себя в этом отношении - они намеревались чего-то достичь, и, возможно, они думали, что это достаточно, чтобы поделиться с сообществом в форме библиотеки, но чаще всего когда-то работа выполнена, они не заинтересованы в улучшении кода или улучшении самих себя (я имею в виду навыки программирования).

Решение может заключаться в том, чтобы в репозиториях библиотек Python (таких как PyPI) были более строгие правила приема принимаемых пакетов - справьтесь с этим с процессом проверки, целью которого является обеспечение качества, - так же, как в основных дистрибутивах Linux процесс проверки был раньше. добавление пакета в свои репозитории.