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

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

Это - одна из многих красот открытого исходного кода.

Часто существует мало смысла в записи партии документации и "хорошего" кода, если Вы не знаете, будет ли проект жить на. Это просто было бы пустой тратой времени.

Править: Конечно, написание хорошего кода никогда не причиняло бы боль в первый раз вокруг хотя... Но возможно просто "получение задания, сделанного", достаточно хорошо во многих случаях. Я думаю, что иначе мы не наслаждались бы огромным количеством опций когда дело доходит до OSS.

Я думаю, что, если достаточно людей действует, особенным методом там могло бы быть некоторое объяснение к нему. Они не просто случайным образом делают так для оскорбления Вас.

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

Качество кода * количество комментариев * время = постоянный

Выберите два!

У меня никогда не было проблемы с помощью matplotlib; не может сказать, что я посмотрел на код очень - это - прекрасная библиотека. Делает то, что это, как предполагается, делает (бесплатно!)

Как насчет набора примеров хорошего документа программного обеспечения?
Хорошие примеры могли бы привести к полному улучшению немного быстрее, чем случайное блуждание.
Набор мог быть разделен на категории, такие как:
встроенный документ / страница справки / учебное руководство / справочник, веб-страница / статья, изображения / ни один.
Каждая запись должна иметь несколько слов на том, почему рецензент находит это хорошим.
(Где: угол stackoverflow?)

PEP8 просто что, конвенция, не требование. Было бы действительно грустно, если бы все программисты Python должны были придерживаться единого набора правил, мы теряем энтузиазм по малейшей из проблем.

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

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

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

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

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

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

PEP8 является руководством по стилю, не требованием стиля. Это даже указывает, что необходимо "знать, когда быть непоследовательными". Лично, мне не нравятся некоторые инструкции в нем. Я предпочитаю camelCase кому: snake_case так как я больше привык к этому.

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

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

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

Относительно сравнения с другими языками я думаю, что дизайн языка играет большую роль здесь. Например, на сильном типизированном языке как Java, даже если библиотека пропускает хорошую документацию, можно все еще вывести большую часть функциональности от сигнатур методов. Нет *args спорить с.

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

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

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

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

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

- Закон об осетрах (перефразируется)

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

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

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

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

Первая вещь, которую необходимо понять, состоит в том, что Python не сделал пружины, полностью сформированной, от головы Guido когда-то вокруг версии 2.x. Это выращено в течение прошлых двадцати лет.

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

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

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

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

Это вызвано тем, что Python не сохранен деловым миром как Java или .NET.

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

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

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

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

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

Ответы здесь не были бы завершены независимо от Закона Осетра: "Девяносто процентов из всего являются дерьмом".