Почему документация PyObjC так плоха?

Основная причина отсутствия документации для PyObjC заключается в том, что есть один разработчик (я), и как большинство разработчиков я не особенно люблю писать документацию. Поскольку PyObjC-это побочный проект для меня, я обычно сосредотачиваюсь на работе над функциями и исправлениями ошибок, потому что это более интересно для меня.

Лучший способ улучшить документацию-это добровольно помочь в списке рассылки pyobjc-dev.

В качестве отступления: pythonmac-sig mailinglist (см. google) является отличным ресурсом для получения справки по Python на MacOSX (а не только по PyObjC).

Я согласен, что этот учебник ошибочен, бросая случайный, необъяснимый код прямо перед вашими глазами. Он вводит такие понятия, как пул авторелиза и пользовательские значения по умолчанию, не объясняя, зачем они вам нужны ("пул Авторелиза для управления памятью" - это вряд ли объяснение).

Вот и все…

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

Я боюсь, что в настоящее время вам понадобится базовое понимание ObjC, чтобы извлечь выгоду из любого языка, который использует Cocoa. PyObjC, RubyCocoa, Nu и другие в лучшем случае являются нишами, и все они были разработаны людьми, близко знакомыми с входами и выходами ObjC и Cocoa.

На данный момент Вы выиграете больше всего, если будете реалистично рассматривать эти мосты как полезные там, где скриптовые языки действительно сияют, а не пытаться построить целое приложение с их помощью. Хотя это было сделано (с LimeChat, я сейчас использую приложение, написанное на RubyCocoa), это редко и, вероятно, будет на некоторое время.

Быть прямолинейным:

Если вы хотите быть эффективным программистом Cocoa, вы должны изучить Objective-C. Конец истории.

Ни Python, ни Ruby не являются заменой объекту-C через их соответствующие мосты. Вам все еще нужно понять цель-C APIs, поведение, присущее NSObject производным классам, и многие другие детали Cocoa.

PyObjC и RubyCocoa-это отличный способ получить доступ к функциям Python или Ruby из приложения Cocoa, включая создание приложения Cocoa в основном - если не полностью-в Python или Ruby. Но успех в нем основан на глубоком понимании Cocoa и цели-C APIs, из которой он состоит.

Ответ Тома и Мартина, безусловно, верен (почти в любом проекте с открытым исходным кодом вы обнаружите, что большинство участников особенно заинтересованы в том, чтобы, ну, развиваться ; не так много в таких полу-связанных вопросах, как документация), но я не думаю, что ваш конкретный вопрос в конце будет хорошо вписываться в документацию PyObjC.

NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None)

NSThread является частью Cocoa API , и как таковой документируется в Apple, включая конкретный метод + detachNewThreadSelector:toTarget:withObject: (я бы связал его, но, по-видимому, stackoverflow имеет ошибки с его разбором). В CocoaDev wiki также есть статья .

Я не думаю, что было бы хорошей идеей для PyObjC попытаться документировать Cocoa, кроме нескольких основных примеров того, как использовать его изнутри Python. Объяснение селекторов также, вероятно, выходит за рамки PyObjC, поскольку они тоже являются особенностью Objective-C, а не конкретно PyObjC.

Я наткнулся на хороший учебник по PyObjC/Cocoa:

http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/

Все, что я хочу сделать, это создать довольно простые приложения Python с Cocoa GUI.. Может ли кто-нибудь пролить свет на ужасную документацию или указать мне на некоторые учебники, которые не просто дают вам огромные блоки кода и предполагают, что вы знаете, что делает NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None)..?

[...]

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

Хотя я в принципе согласен с ответом Соэрена, я бы пошел еще дальше:

Пройдет много времени, если вообще когда-нибудь, прежде чем вы сможете использовать Cocoa без некоторого понимания цели C. Cocoa-это не абстракция, построенная независимо от объекта C, она явно привязана к нему. Вы можете увидеть это в приведенном выше примере строки кода:

NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None) 

Это Python способ написания строки Objective C:

[NSThread detachNewThreadSelector:@selector(queryController:) toTarget:self withObject:nil];

Теперь важно отметить, что эта линия может рассматриваться двумя способами: (1) как линия объективного C, или (2) как вызов фреймворков Cocoa. Мы видим его как (1) по синтаксису. Мы рассматриваем его как (2), признавая, что NSThread-это фреймворк Cocoa, который предоставляет набор удобных функций. В этом случае этот конкретный фреймворк Cocoa позволяет нам легко заставить объект начать делать что-то в новом потоке.

Но самое интересное заключается в следующем: фреймворк Cocoa здесь (NSThread) предоставляет нам этот удобный сервис таким образом, что он явно привязан к языку, на котором был написан фреймворк. А именно, NSThread дал нам функцию, которая явно относится к "selectors". Селекторы-это, по сути, название для чего-то фундаментального в том, как работает Objective C.

Так вот в чем загвоздка. Cocoa по своей сути является объективным творением-C, и его создатели построили его с учетом объективного C. Я не утверждаю, что невозможно перевести интерфейс к функциям Cocoa в форму, более естественную для других языков. Просто как только вы меняете фреймворк Cocoa, чтобы перестать ссылаться на "selectors", это уже не совсем фреймворк Cocoa. Это переводная версия. И как только вы начинаете идти по этому пути, я предполагаю, что все становится очень запутанным. Вы пытаетесь идти в ногу с Apple, когда они обновляют Cocoa, возможно, вы попали в некоторые части Cocoa, которые просто не очень хорошо переводятся на новый язык, что угодно. Поэтому вместо этого такие вещи, как PyObjC, предпочитают выставлять Cocoa напрямую, таким образом, чтобы иметь очень ясную и простую корреляцию. Как говорится в документации:

Для того, чтобы иметь без потерь и однозначный перевод между Objective-C сообщениями и Python методами, эквивалент имени метода Python-это просто селектор с двоеточиями, замененными подчеркиванием.

Конечно, это немного уродливо, и это означает, что вам нужно знать что-то об объективном-C, но это потому, что альтернатива, если она действительно существует, не обязательно лучше.

Я вообще ничего не знал о Objective C или Cocoa (но много о Python), но сейчас я пишу довольно сложное приложение в PyObjc. Как я этому научился? Я взял Cocoa программирование для OSX и прошел через всю книгу (довольно быстрый процесс), используя PyObjC. Просто игнорируйте все, что касается управления памятью, и все будет в порядке. Единственный нюанс заключается в том, что очень редко вам приходится использовать декоратор, подобный endSheetMethod (на самом деле я думаю, что это единственный, кого я ударил):

@PyObjcTools.AppHelper.endSheetMethod
def alertEnded_code_context_(self, alert, choice, context):
    pass

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

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