python osx cocoa pyobjc

python - ¿Por qué la documentación de PyObjC es tan mala?



osx cocoa (9)

Por ejemplo, http://developer.apple.com/cocoa/pyobjc.html sigue siendo para OS X 10.4 Tiger, no para 10.5 Leopard ... Y esa es la documentación oficial de Apple para ello ..

La página oficial de PyObjC es igualmente mala, http://pyobjc.sourceforge.net/

Es tan malo que es desconcertante. Estoy considerando aprender a Ruby principalmente porque las cosas de RubyCocoa están mucho mejor documentadas, y hay muchos tutoriales decentes ( http://www.rubycocoa.com/ por ejemplo), y debido a los Zapatos GUI toolkit ..

Incluso este tutorial japonés mal traducido automáticamente es más útil que el resto de la documentación que pude encontrar.

Todo lo que quiero hacer es crear aplicaciones Python bastante simples con la GUI de Cocoa.
¿Alguien puede arrojar luz sobre la horrible documentación, o señalarme algunos tutoriales que no solo te dan bloques de código enormes y supongo que sabes lo que hace NSThread.detachNewThreadSelector_toTarget_withObject_("queryController", self, None) ...?

Estoy de acuerdo en que ese tutorial es defectuoso, arrojando un código aleatorio e inexplicable justo en frente de tus ojos. Introduce conceptos como el grupo de autorrelease y los valores predeterminados del usuario sin explicar por qué los querría ("Autorelease pool for memory management" no es una explicación).

Eso dijo ...

básicamente, todo lo que quiero hacer es escribir aplicaciones Cocoa sin tener que aprender ObjC.

Me temo que, por el momento, necesitará una comprensión básica de ObjC para beneficiarse de cualquier idioma que use Cocoa. PyObjC, RubyCocoa, Nu y otros son nichos en el mejor de los casos, y todos fueron desarrollados por personas íntimamente familiarizadas con los pormenores de ObjC y Cocoa.

Por ahora, se beneficiará más si considera que esos puentes son realmente útiles cuando realmente brillan los lenguajes de scripting, en lugar de tratar de construir una aplicación completa con ellos. Mientras esto se ha hecho (con LimeChat, estoy usando una aplicación escrita por RubyCocoa en este momento), es raro y probablemente lo sea por un tiempo.

Esta respuesta no va a ser muy útil, pero, como desarrollador, odio hacer documentación. Al tratarse de un proyecto de código abierto, es difícil encontrar personas para documentar.

La respuesta de Tom y Martin es definitivamente cierta (en casi cualquier proyecto de fuente abierta, encontrará que la mayoría de los contribuyentes están particularmente interesados ​​en, bueno, en el desarrollo , no tanto en cuestiones semi relacionadas como la documentación), pero yo no piense que su pregunta particular al final encajaría bien dentro de la documentación de PyObjC.

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

NSThread es parte de Cocoa API y, como tal, está documentado en Apple , incluido el método particular + detachNewThreadSelector:toTarget:withObject: (Me gustaría enlazar allí, pero aparentemente tiene errores al analizarlo). La wiki de CocoaDev también tiene un artículo .

No creo que sea una buena idea que PyObjC intente documentar Cocoa, aparte de algunos ejemplos básicos de cómo usarlo desde Python. Explicar los selectores también es probable que esté fuera del alcance de PyObjC, ya que esos también son una característica de Objective-C, no de PyObjC específicamente.

Tom dice todo realmente. Muchos proyectos de código abierto tienen desarrolladores dedicados y pocos que están interesados ​​en documentar. No ayuda el hecho de que los postes del objetivo pueden cambiar diariamente lo que significa que la documentación no solo debe crearse sino también mantenerse.

Todo lo que quiero hacer es crear aplicaciones Python bastante simples con las GUI de Cocoa. ¿Alguien puede arrojar luz sobre la horrible documentación, o señalarme algunos tutoriales que no solo te dan bloques de código enormes y supongo que sabes lo que NSThread.detachNewThreadSelector_toTarget_withObject_ ("queryController", self, None) does ..?

[...]

básicamente, todo lo que quiero hacer es escribir aplicaciones Cocoa sin tener que aprender ObjC.

Aunque básicamente estoy de acuerdo con la respuesta de Soeren, lo llevaría aún más lejos:

Pasará mucho tiempo, o nunca, antes de que puedas usar Cocoa sin una cierta comprensión del Objetivo C. El cacao no es una abstracción construida independientemente del Objetivo C, está explícitamente ligada a él. Puede ver esto en la línea de ejemplo de código que citó anteriormente:

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

Esta es la forma en Python de escribir la línea Objective C:

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

Ahora, es importante notar aquí que esta línea se puede ver de dos maneras: (1) como una línea del Objetivo C, o (2) como una invocación de los marcos de Cocoa. Lo vemos como (1) por la sintaxis. Lo vemos como (2) al reconocer que NSThread es un marco Cocoa que proporciona un conjunto de características útiles. En este caso, este marco particular de Cocoa nos facilita tener un objeto que comience a hacer algo en un nuevo hilo.

Pero el truco es este: el marco de Cocoa aquí (NSThread) nos proporciona este práctico servicio de una manera que está explícitamente ligada al lenguaje en el que se ha escrito el marco. A saber, NSThread nos dio una característica que explícitamente se refiere a "selectores" . Los selectores son, de hecho, el nombre de algo fundamental sobre cómo funciona el Objetivo C.

Entonces está el problema. El cacao es fundamentalmente una creación de Objective-C, y sus creadores lo han construido con Objective C en mente. No pretendo que sea imposible traducir la interfaz a las funciones de Cocoa en una forma más natural para otros idiomas. Es solo que tan pronto como cambias el marco de trabajo de Cocoa para dejar de referirse a "selectores", ya no es realmente el marco de trabajo de Cocoa. Es una versión traducida. Y una vez que empiezas a ir por ese camino, supongo que las cosas se ponen realmente desordenadas. Intentas mantener el ritmo de Apple mientras actualizan Cocoa, tal vez tocas algunas partes de Cocoa que simplemente no se traducen bien en el nuevo idioma, lo que sea. Entonces, en cambio, cosas como PyObjC optan por exponer Cocoa directamente, de una manera que tiene una correlación muy clara y simple. Como dicen en la documentación:

Para tener una traducción sin pérdidas y sin ambigüedades entre los mensajes de Objective-C y los métodos de Python, el equivalente del nombre del método de Python es simplemente el selector con dos puntos reemplazados por guiones bajos.

Claro, es un poco feo, y significa que necesitas saber algo sobre Objective-C, pero eso se debe a que la alternativa, si realmente existe, no es necesariamente mejor.

Para ser honestos:

Si quieres ser un programador efectivo de Cocoa, debes aprender Objective-C. Fin de la historia.

Ni Python ni Ruby son un sustituto de Objective-C a través de sus respectivos puentes. Aún debe comprender las API de Objective-C, los comportamientos inherentes a las clases derivadas de NSObject y muchos otros detalles de Cocoa.

PyObjC y RubyCocoa son una excelente forma de acceder a la funcionalidad de Python o Ruby desde una aplicación Cocoa, incluida la construcción de una aplicación Cocoa principalmente, si no del todo, en Python o Ruby. Pero el éxito se basa en una comprensión exhaustiva de Cocoa y las API de Objective-C de las que está compuesta.

No sabía nada sobre Objective C o Cocoa (pero sí mucho sobre Python), pero ahora estoy escribiendo una aplicación bastante compleja en PyObjc. ¿Cómo aprendí? Recogí Cocoa Programming for OSX y revisé todo el libro (un proceso bastante rápido) usando PyObjC. Simplemente ignore todo lo relacionado con la gestión de la memoria y prácticamente estará bien. La única advertencia es que muy ocasionalmente tienes que usar un decorador como endSheetMethod (de hecho, creo que es el único al que he golpeado):

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

La razón principal de la falta de documentación para PyObjC es que hay un desarrollador (yo) y, como la mayoría de los desarrolladores, no me gusta particularmente escribir documentación. Como PyObjC es un proyecto paralelo para mí, tiendo a centrarme en trabajar en funciones y correcciones de errores, porque eso es más interesante para mí.

La mejor manera de mejorar la documentación es ofrecerse como voluntario para ayudar en la lista de correo de pyobjc-dev.

Como comentario adicional: la lista de correo pythonmac-sig (ver google) es un excelente recurso para obtener ayuda sobre Python en MacOSX (no solo PyObjC).