Документация - часто неполная или отсутствует

Это не следствие динамической типизации.

я не спорю. Но такая ситуация встречается очень часто. Просто с динамически типизированным языком она переносится болезненно.

Использую ipython, там дополнение методов по TAB'у плюс вызов документации (кстати, в тех либах, которые я использую в своих проектах, она обычно вполне на уровне). Но согласен, в статике IDE пофичастее будут.

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

Сами типы могут сказать очень многое.

разница есть. В стат. тип. языке я сделаю N раз go to definition, и вот он - список всех членов.

В дин. тип. языке я попытаюсь 1 раз go to definition, на что IDE тупо не отреагирует - тип определить нельзя :)

Это не документация. Так и я могу в repl'е добраться до нужного члена.

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

Я к тому, что описанные мной и тобой методы к документации отношения не имеют. Документация — это то, что на сайте разработчика висит в html и pdf.

Это не документация.

что бы это ни было - задачей оно справляется отлично.

А можно вопрос — _зачем_ тебе знать тип переменной. Если ты туда сохраняешь строку — это будет строка, если цифру — то цифра, разве не так? Как ты используешь знание о типе переменной? Насколько это критично?

Это важно, когда надо у какой-то переменной из стороннего модуля вызвать метод. Ты сидишь в IDE и не знаешь, какие вообще методы у нее есть.

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

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

Но ты же его включаешь, и должен знать что за класс ты используешь. Нет?

Откуда знаешь? Допустим, у этого модуля нет документации. Или есть, но не все классы.

но если я использую какую-то переменную (читай инстанс класса), то обычно я знаю что я делаю и какие методы есть у класса

Когда пишешь - да. Когда через год-два тебе нужно перечитать большой проект с целью что-то пофиксить/улучшить - тут уже интересней.

Если нужно вызвать метод/обратиться к члену на крайняк есть getattr. Ваш КО.

ТС-у: у Вас странные желания, но со врнменем это пройдет. Удобнее всего таб в интерпретаторе.

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

Есть ли какая-нибудь удобная тула для навигации по docstrings?

sphinx.

эта проблема с питоном сильно тормозит разработку.

Это только поначалу, пока stdlib в подкорке не улегся.

Простите за нубский вопрос, но как докстроки помогают узнать с каким конкретно классом имеешь дело, например в теле метода/функции? Типы-то в аргументах не прописаны.

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

Вернее, какие методы как работают и какие аргументы принимают.

Нужно больше лиспа

Тут не хватает лиспа

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

Или там типа сидит такой ИИ и смотрит - о, чей то мне тут поишло? Акак у этой байды вызывается отрисовка, дай ка докчтринг распарсю!:-)

Если приходиться угадывать, значит в дизайне косяк.

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

вместо

dir(something)

help(something)

Еще можно попробовать освоить язык по хорошему учебнику.

Самые обычные желания

проблема не столько в динамической типизации, сколько в возможности динамически изменять список членов класса/объекта. очень сильная фича. если она не используется, то автодополнение должно работать нормально. если используется - то обязательно должна быть внятная документация, тут уж ничего не поделать.

в дизайне косяк.
просто очень раздутый проект, в котором трудно быстро найти связи и что куда приходит.

отличный эвфемизм

В критических местах можно ставить ручную проверку типов, можно замутить прлверку типов аргументлв функции через декоратлр

AIv всегда готов предложить парочку извращенных решений, замешанных на интроспекции ;)

При достаточно развитой системе типов сигнатуры становятся отличной, а главное, автоматически верифицируемой документацией. Это, правда, не про жаву совсем.

Да, только ни то ни то к интроспекции не относится:-)

Это неизлечимая анальная боль динамических языков. Через некоторое время тебе может начать нравится и ты начнёшь себя считать Элитой :D

Всем спасибо за ответы.

ipython и sphinx определённо пригодятся.

можно глянуть вот эту тулзу от фейсбука https://github.com/facebook/pfff/wiki/Main

она с питоном еще не доконца работает да и вообще еще сыровата но в некоторых случаях может помочь если нужно в большом проекте разобратся

http://www.youtube.com/watch?v=HRZjBGD3osw http://www.youtube.com/watch?v=993pmNLY_VU

Тип переменной не имеет такого большого значения, как в статических языках, потому что соответствие типов нигде не проверяется. Любой объект можно собрать вручную на основе dict операциями добавления и удаления полей.

Dynamic typing - зло, Static typing + type inference - благо.

тебе надо знать интерфейс и использовать его, тебе не надо знать тип и прочую ерунду.

не знаешь интерфейс... требуй постановку задачи и не берись за говнокод(если за это конечно не платят приличных денег)

4. Переход на нормальные языки со статической типизацией.

Вообще, это довольно самонадеянно - использовать чужой модуль, не зная, как он устроен внутри и не имея исчерпывающей документации на этот счёт. Сейчас-то Вы, конечно, посмотрите, какие у него есть методы и поля, но завтра автор выкатил новую версию, изменив реализационную часть (он-то, наивный, думает, что всё, что не публично, сторонним кодом не используется), и, оп-па, деда, ты попал!

Ну а, вообще, ТС уже все слова сказал сам: dir(smth). Я подозреваю, что автокомплит во многих средах так и реализован.

Static typing + type inference - благо

Маловато будет. Надо ещё type ака FCO. И наличие в том числе и «прототипированных» возможностей: определение интерфейса как набора «свойств» по уже существующей «иерархии классов», расширение уже где-то созданных объектов, может ещё что - сразу и не скажу.

тебе надо знать интерфейс и использовать его, тебе не надо знать тип и прочую ерунду.

Хех, забавная логика :)

Чтобы УЗНАТЬ интерфейс, нужно получить список членов. Тип, так или иначе, в этом сильно поможет.

не знаешь интерфейс... требуй постановку задачи и не берись за говнокод

эммм... Неужели вы бросаете задачу каждый раз, когда вам не удаётся осилить интерфейсы :) ? Постановка задачи тут не причём.

Вообще, это довольно самонадеянно - использовать чужой модуль, не зная, как он устроен внутри и не имея исчерпывающей документации на этот счёт

не зная, как он устроен внутри

Вы слышали что такое инкапсуляция?

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

не имея исчерпывающей документации на этот счёт

Реальность такова, что «исчерпывающей документации» очень часто не бывает.

Иногда дира недостаточно, если перегружен __getattr__

Я рекомендовал бы посмотреть предыдущую переписку, прежде чем.

Вы слышали что такое инкапсуляция?

Это когда нельзя посмотреть как оно работает?

Вы слышали что такое инкапсуляция?

Это когда нельзя посмотреть как оно работает?

Нет, это называется «быдлокод^Wобфускация».

Эх :-) А кому щаз легко. Если перегружены __getattr__ и, в особенности, __getattribute__ , задача определения атрибутов объекта становится принципиально не определяемой снаружи, только полным анализом кода :)

Это когда нельзя посмотреть как оно работает?

Это когда неважно как оно работает.

Чтобы УЗНАТЬ интерфейс, нужно получить список членов.

ты пишешь код, который обрабатывает объекты с неизвестным интерфейсом? И ты в рантайме определяешь интерфейс через тип, чтобы организовать нужное взаимодействие?

это кривая архитектура, это нужно переделать. Диспетчеризация на основе типа в питоне, это странно.

В общем случае да. Но в некоторых актуальных частных случаях можно пропатчить dir или ее аналоги. Например SWIG для оберток плюсовых классов перегружает __getattr__, но (выясняется путем анализа кода;-)) все атрибуты лежат в словарях __swig_get/setattribute__, откуда их и надо брать. С дургой стороны в __dict__ SWIG кладет всякую муру типа this и thisown которую трогать не надо.

Я с-но к чему - код смотреть все равно приходиться.

Ох, ну swig - это отдельная песня. Я тут давеча организовывал следующую конструкцию:

Java program -> C++ library -> Java callback based on С++ interface. Со сквозными эксепшнами и разнообразными контейнерами.

На удивление, всё заработало, и заняло ~неделю. Но не оставляло ощущение изучения «Искусства Тёмных Сил».