elpy - Comparación de los modos de Python para Emacs

emacs for windows (2)

Así que tengo Emacs 24.3 y con él viene un archivo python.el bastante reciente que proporciona un modo de Python para la edición.

Pero sigo leyendo que hay un python-mode.el en Launchpad , y comparando los dos archivos me sale que el primero tiene menos de 4000 líneas, mientras que el segundo es casi 20000. Esto sugiere que el último es mucho más característica -Rico.

Y no puedo encontrar ninguna comparación de funciones en línea sobre ellos, documentación o, al menos, una lista sobre las características de cada uno de ellos. Sí, hay resaltado de sintaxis e intérprete incrustado, pero ¿qué ocurre con la finalización en el búfer de shell, la finalización en el búfer de archivos de origen, la autoinscripción, el reinicio, etc.

Entonces, ¿cuáles son las características importantes de estos modos? (O cualquier otro modo de Python para Emacs que recomiende). Proporcione respuestas detalladas.

Al estar muy involucrado en el desarrollo de python-mode.el últimos años, mi comentario probablemente sea parcial: Recomiende quedarse con python.el para principiantes de Emacs. También su autor merece crédito por algunos enfoques útiles.

python-mode.el está diseñado para aumentar la productividad de ediciones. Hace que sea fácil ejecutarlo o ejecutarlo a través de shells python2 y python3 o IPython en paralelo.

Reduce la cantidad de pulsaciones de teclas necesarias que proporcionan comandos personalizados. Hace que las ediciones sean más rápidas, ayuda a programar por voz, entrada impulsada por macro, etc.

Admite funciones de lenguaje Python desconocidas por python.el actualmente:

py-up, py-down - bloques anidados que viajan

Evite los errores tipográficos al buscar formularios en el punto, una cláusula, por ejemplo:

py-backward-clause py-copy-clause py-down-clause

...

No es necesario personalizar al probar diferentes versiones:

py-execute-clause-python2 py-execute-clause-python3 py-execute-clause-ipython

...

noción de partes de grano más fino - py-expression , py-minor-expression
comandos ejecutando versioned y parallelled (I) Python-executables, no es necesario volver a definir el Python predeterminado
eliminando en gran medida la necesidad de una región activa marcada anteriormente, vea py-execute-line y mucho más

Para obtener una visión general, eche un vistazo al menú. El directorio "doc" enumera los comandos.

A medida que aumenta la calidad del código: una forma de comparar ambos modos es probablemente la búsqueda de los errores enumerados en http://debbugs.gnu.org/ . Ver por ejemplo el error # 15510, # 16875; o http://lists.gnu.org/archive/html/help-gnu-emacs/2014-04/msg00250.html

Ya se comentó en "granularidad aproximada de compromiso": aunque básicamente es correcto buscar piezas más pequeñas, a veces las condiciones me obligan a abandonar la regla. Las partes considerables no están escritas a mano, sino por programas que residen en el directorio "desarrollo". Crean archivos utilizados en la rama de desarrollo frist, es decir, componentes-python-mode. Al comenzar una nueva característica, a menudo no es obvio si la ruta elegida es fructífera. Después de un centenar de posibles compromisos, todavía puede resultar imposible o no tan recomendable. En lugar de publicar todos los meandros, se usa para mantener esa rama experimental durante varios días en estos casos y se registra cuando pasan las pruebas.

Por cierto, supongamos que tkf se refiere no a errores de compilación, que se buscarían instantáneamente, sino a advertencias del compilador. Desafortunadamente, Emacs mezcla advertencias sobre preferencias de estilos respaldados con errores reales.

Fui usuario de python-mode.el una vez pero dejé de usarlo hace un año porque sentía que la forma en que se desarrolló no estaba bien organizada. Aquí hay una lista de la nota que tomé en ese momento. Pero necesito advertirles que ha pasado casi un año desde entonces, por lo que la situación puede cambiar.

Muchas funciones de copiar y pegar.
Muchos códigos de trabajo accidental. Por ejemplo, no pasando por las variables pero usando el enlace implícito. Esto produce muchos errores de compilación (y no funcionará si lo cambia a un alcance léxico).
Granularidad aproximada de commit. Envío un parche, y fue cometido con cambios no relacionados.

Una cosa que me gusta de python-mode.el es que viene con un conjunto de pruebas automático (aunque nunca lo he ejecutado). python.el aún no tiene un conjunto de prueba. Pero sé que el autor de python.el lo está escribiendo ahora.

Si bien python.el es compacto, no significa que obtenga una funcionalidad deficiente. Es más como mantener el núcleo pequeño y permitir que otros lo extiendan al proporcionar una API concisa. El mismo autor de python.el escribió python-django.el para extender python.el para proyectos django. Escribí el complemento de Jedi.el para Python llamado Jedi.el y el complemento avanzado de IPython llamado EIN . Ambos tienen mejor soporte para python.el que python-mode.el (bueno, eso es porque no uso python-mode.el, sin embargo).

Tuve algunas cosas que me perdí de python-mode.el primero, pero se arreglan rápidamente en python.el (por supuesto, esto probablemente significa que no estaba usando tanta funcionalidad en python-mode.el).

¿Qué pasa con la finalización en el buffer de shell, la finalización en el buffer de archivos de origen, autoindentificación, etc.

finalización en el búfer de shell: funciona de alguna manera en python.el y python-mode.el. Pero a veces no funciona si tiene mala combinación de la versión de Emacs y la versión de python (-mode) .el. Entonces, es probable que python.el sea más seguro de esta manera. Pero si quieres una mejor solución, usa EIN :)
finalización en el buffer de archivos fuente: solo use Jedi.el :)
autoindent / reindent: No sé cuál es mejor en cuanto a rendimiento. Sin embargo, la clave de retorno difiere una de la otra. En python-mode.el, si escribe RET obtiene autoindent. En python.el, RET no le da sangría y debe usar Cj en su lugar. En realidad, Cj para nueva línea + sangría es un comportamiento universal en Emacs. Entonces python.el es mejor si lo hace programando en otros idiomas.