2Андрей Светлов:

Чтение и понимание питон-кода очень сильно осложнено динамической природой самого питона. порою глядишь на аргументы функции в чужом исходнике и пытаешься угадать, что это может быть. Потому как если передается объект какого-то класса из этой же либы (а их в либе может быть очень много), то нужно знать какого класса, чтобы понимать что он может делать или делает. Про наследование, особенно множественное, я уже молчу. Иногда проще в рантайме заняться просмотром dir(some_var).
Поэтому если нет докстрингов к функциям и классам – то в особо накрученных случаях можно сразу тушить свет.
У нас в проекте Bazaar очень большое внимание уделяется документированию. А ведь тоже опенсорс проект вроде… Так что не стоит так сильно обобщать, что никто ничего кроме кода не пишет. Тот кто пишет только код для себя и забывает про читателей – у того будет мало пользователей. Как это в известной цитате: “код пишется в первую очередь для чтения людьми и только в последнюю очередь для исполнения машиной”. Немало есть и плохого кода на питоне. Но новичкам может оказаться трудно распознать это.

А иногда авторы исходников начинают пользоваться всякими магическими штучками питона – их если не знаешь, то никогда не угадаешь. Тут туториалы точно не помогут.

Вобщем я не согласен с Вами в некоторых особо категоричных моментах. По личному опыту: на освоение любого дела нужно минимум 9 месяцев. Сначала почитать книги, самому потыкаться, а потом начинать читать исходники. Сразу начинать читать исходники – ну разве что легкие какие-нибудь. Из книг-туториалов :-)
Это вообще известный факт: за пару недель можно выучить 80% почти любого языка программирования, однако на оставшиеся 20% придется потратить годы. И чаще всего правильное и виртуозное владение языком как раз заключается в этих 20%.

Я могу дать совет новичкам: изучайте чужой исходный питон-код, с которым вы работаете, через отладчик (debugger). Так вы сразу увидите КАК работает код, а не ЧТО он означает. И кстати, я перепробовал много GUI-дебагеров, но совсем недавно научился работать со стандартным pdb (командная строка), и хочу сказать, что он удобнее в РАЗЫ. Рекомендую.

Также рекомендую распечатать и все время перечитывать PEP-8, и естественно следовать его рекомендациям. Это окупится.

bialix
Чтение и понимание питон-кода очень сильно осложнено динамической природой самого питона.

Для меня это самая большая проблема в питон. Так что жду ру3.

bialix
И кстати, я перепробовал много GUI-дебагеров, но совсем недавно научился работать со стандартным pdb (командная строка), и хочу сказать, что он удобнее в РАЗЫ.

Согласен, только я больше ч-з print или файл.

Я никогда не понимал тех “писателей”, которые не пишут докстрингов. Ведь это отказ от мощнейшего средства самодокументирования кода. Есть одно правило проверенное временем - время которое экономиться на написание комментов/докстрингов будет тратится на понимение кода, и это будет повторяться снова и снова. Даже если для библиотеки написана внятная документация лежащяя у меня на диске это не повод по тридцать раз на дню лезть в нее, если я забыл в каком порядке идут параметры функции.

bialix
Спасибо, я действительно иногда был слишком экстремален.
Да и тема расползлась: документирование и статьи, русский и английский.

Давайте остановимся только на первом. Оно тоже не монолитно. tutorial-using-reference.
reference на Питоне хорошо решаются докстрингами. И писать их - нужно. Кто бы спорил.
Зачастую они довольно хороши, но без заглядывания в исходники всей проблемы не покрывают.
И я никогда не говорил, что читая исходники закрываю глаза на доки и комментарии.

tutorial и using пишутся, конечно же. Но описывают лишь самые торные пути. И их всегда недостаточно.
Именно эти вещи я и считаю документацией, как деятельностью, отделенной от создания кода.

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

Затронут еще один интересный момент: отладка, используемая для изучения.
Да, да и еще раз да.
Логирование, сделано оно через print или logging (стандартный модуль или специфическую подсистему) сильно помогает.
Интерактивный отладчик - тоже. И я сам перешел от GUI отладчиков к pdb. import pdb;pdb.set_trace() - отличное средство.
Постоянно применяю.

Cleric, я достаточно ясно описал свое мнение?
Самодокументирование - это внятные идентификаторы и комментарии. И если питон позволяет писать комментарии, попадающие в reference - этим тоже стоит пользоваться.

lorien
А там что?

ещё больше магии в 3000 будет.

lorien

Для меня это самая большая проблема в питон. Так что жду ру3.

А там что?

Мне думается. что имелось в виду это: http://www.python.org/dev/peps/pep-3107/

А вот другой вопрос. Видите ли вы в будующем подъём популярности этого языка или перестановки сил не придвидится? и если да то какие сроки?

offline
Видите ли вы в будующем подъём популярности этого языка или перестановки сил не придвидится? и если да то какие сроки?

А он и так достаточно популярен. Он занял свою нишу, сейчас чуть-чуть отваёвывает область веб-программирования. Ждать того что он выйдет на уровень С++ и Java, мне кажется, не стоит. Да и не нужно это наверно. Комьюнити уж больше хорошее,а при большей попсовости может ипортиться:)

Daevaorn
И какая же ниша у Питона, позвольте полюбопытствовать? Если он ее занял?

Андрей Светлов
И какая же ниша у Питона, позвольте полюбопытствовать? Если он ее занял?

прикладыне скрипты( шелл, автоматизация и т.п.), в некоторой степени научные расчеты, DSL