¿Hay una convención de nomenclatura de paquete para Python como la de Java com.company.actualpackage? La mayoría de las veces veo nombres de paquetes simples, potencialmente colisionantes, como "web".Convenciones de nombre de paquete de Python
Si no existe tal convención, ¿hay alguna razón para ello? ¿Qué piensas de usar la convención de nomenclatura de Java en el mundo de Python?
Python tiene dos "mantras" que cubren este tema:
Explícito es mejor que implícito.
y
Los espacios de nombres son una gran idea que toca la bocina - vamos a hacer más de esos!
Existe una convención para el nombre y la importación de módulos que se pueden encontrar en The Python Style Guide (PEP 8).
La razón más importante por la que no existe una convención de este tipo que prefiera los nombres de sus módulos en un estilo Java, es porque con el tiempo termina con mucha repetición en el código que realmente no necesita estar allí.
Uno de los problemas con Java es que te obliga a repetirte constantemente. Hay una gran cantidad de repetición de código Java que simplemente no es necesario en Python. (Getters/setters es un excelente ejemplo de eso.)
Los espacios de nombres no son un problema tan grande en Python porque es posible dar a los módulos un alias en la importación. Tales como:
import com.company.actualpackage as shortername
Así que no sólo es capaz de crear o manipular el espacio de nombres dentro de sus programas, pero son capaces de crear sus propios alias de ahorro de pulsaciones de teclas también.
He estado usando python durante años y el 99.9% de las colisiones que he visto provienen de nuevos desarrolladores que intentan nombrar un archivo "xml.py". Puedo ver algunas ventajas en el esquema de Java, pero la mayoría de los desarrolladores son lo suficientemente inteligentes como para elegir nombres de paquetes razonables, por lo que realmente no es un gran problema.
El problema "xml.py" (nombrar una secuencia de comandos que sombrea accidentalmente un módulo incorporado) se debe más a que las secuencias de comandos son módulos * y * al directorio del script que se busca módulos que los nombres no obvios. Las personas que llaman a su script 'xml.py' por lo general no esperan que se importe con 'import xml'. –
Los desarrolladores experimentados no nombrarían un script 'xml.py' y esperan hacer 'import xml', pero afirmé claramente que esto era un problema para los nuevos desarrolladores. – mikerobi
La razón por la que normalmente no hay jerarquía de paquetes es porque los paquetes de Python no se pueden extender fácilmente de esa manera. Los paquetes son directorios reales, y aunque puede hacer que los paquetes aparezcan en múltiples directorios para los submódulos (agregando directorios a la lista __path__ del paquete) no es conveniente y se hace fácilmente incorrectamente. En cuanto a , por qué los paquetes de Python no se extienden fácilmente de esa manera, bueno, esa es una opción de diseño. A Guido no le gustaban las jerarquías profundas (y aún no lo hace) y no cree que sean necesarias.
La convención es elegir un nombre de paquete de nivel que sea obvio pero exclusivo para su proyecto, por ejemplo, el nombre del proyecto en sí. Puedes estructurar todo dentro de ti como quieras (porque tienes el control). Dividir el paquete en bits separados con propietarios separados es un poco más laborioso, pero con algunas pautas es posible. Rara vez es necesario.
Las convenciones de Java también tienen sus propios inconvenientes. No todos los paquetes de código abierto tienen un sitio web estable detrás de él. ¿Qué debe hacer un mantenedor si su sitio web cambia? Además, al utilizar este esquema, los nombres de los paquetes se vuelven largos y difíciles de recordar. Finalmente, el nombre del paquete debe representar el propósito del paquete, no su propietario
+1 totalmente de acuerdo –
La razón para usar nombres de dominio es utilizar un espacio de nombre bajo el control del propietario del proyecto. Pero sería confuso si el sitio difiere de los nombres de paquete ... – deamon
@deamon El problema en la respuesta es qué hacer si no tiene ningún dominio que controle, lo cual es cierto para muchas personas – Mark
No existe una convención de nomenclatura similar a Java para los paquetes de Python. Por supuesto, puede adoptar uno para cualquier paquete que desarrolle usted mismo, pero es posible que deba editar de forma invasiva cualquier paquete que pueda adoptar de terceros, y la convención de nomenclatura "culturalmente ajena" probablemente socavará los cambios de sus propios paquetes para ser ampliamente adoptados. fuera de su organización.
Técnicamente, no habría nada de malo con la convención de Java en Python (simplemente haría algunas declaraciones from un poco más largas, no es gran cosa), pero en la práctica los aspectos culturales hacen que sea prácticamente inviable.
No hay nada que te impida usar esa convención si quieres, pero no es del todo estándar en el mundo de Python y probablemente obtendrías un aspecto extraño. No es muy divertido ocuparse de la administración en los paquetes cuando están profundamente anidados en com.
Puede sonar descuidado para alguien que viene de Java, pero en realidad no parece haber causado grandes dificultades, incluso con paquetes tan poco conocidos como web.py.
El lugar donde a menudo se hace conflictos get espacio de nombres en la práctica es la importación relativos: donde el código en package.module1 intentos para import module2 y hay tanto una package.module2 y una module2 en la biblioteca estándar (que no es comúnmente como el stdlib es grande y creciendo). Afortunadamente, las importaciones relativas ambiguas are going away.
Ehm, es un poco difícil hacer una importación absoluta en lugar de una importación relativa por accidente, teniendo en cuenta que las importaciones absolutas deben activarse explícitamente. El problema común es al revés: intentar importar un módulo stdlib desde un paquete que tiene un módulo con el mismo nombre. No se debe a la falta de jerarquía de paquetes (porque está en un paquete), sino a la importación implícita relativa de la que Python se deshace en 3.x. –
Ah, sí, de acuerdo ... reformulando. – bobince
+1 para alias con la palabra clave 'as' – n611x007