nomenclatura convenciones python naming-conventions namespaces packages

convenciones - pep8 python 3



Convenciones de nombre de paquete de Python (7)

¿Existe una convención de nomenclatura de paquetes para Python como com.company.actualpackage de Java? La mayoría de las veces veo nombres de paquetes simples y potencialmente colisionables como " web ".

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?


He estado usando python durante años y el 99.9% de las colisiones que he visto de nuevos desarrolladores tratando de nombrar un archivo "xml.py". Puedo ver algunas ventajas del 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 problema tan grande.


La razón por la que normalmente no hay una jerarquía de paquetes es porque los paquetes de Python no se extienden fácilmente de esa manera. Los paquetes son directorios reales, y aunque puede hacer que los paquetes se vean en varios directorios para los submódulos (agregando directorios a la lista __path__ del paquete) no es conveniente, y es fácil hacerlo de forma incorrecta. 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 le gustan) y no cree que sean necesarias.

La convención es elegir un nombre de paquete de alto nivel que sea obvio pero exclusivo de su proyecto, por ejemplo, el nombre del proyecto en sí. Puede estructurar todo lo que esté dentro de él como desee (porque tiene el control del mismo). Dividir el paquete en bits separados con propietarios independientes es un poco más de trabajo, 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 OpenSource tienen un sitio web estable detrás. ¿Qué debe hacer un mantenedor si cambia su sitio web? Además, los nombres de paquetes de este esquema se vuelven largos y difíciles de recordar. Finalmente, el nombre del paquete debe representar el propósito del paquete, no su propietario


No hay nada que te impida usar esa convención si lo deseas, pero no es del todo estándar en el mundo de Python y es probable que tengas una apariencia divertida. No es muy divertido ocuparse de admin 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 mal nombrados como web.py.

En la práctica, el lugar en el que a menudo obtiene conflictos de espacio de nombres es las importaciones relativas: donde el código en package.module1 intenta import module2 y hay un package.module2 y un module2 en la biblioteca estándar (que comúnmente existe como el stdlib es grande y creciente). Afortunadamente, las importaciones relativas ambiguas van desapareciendo .


No hay 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 tenga que editarlo de forma invasiva de terceros, y la convención de nombres "culturalmente ajena" probablemente socavará los cambios de sus propios paquetes para ser ampliamente adoptado. fuera de su organización.

Técnicamente, no habría nada de malo con la convención de Java en Python (solo haría que algunas afirmaciones fueran un poco más largas, no es gran cosa), pero en la práctica, los aspectos culturales hacen que sea prácticamente inviable.


Python tiene dos "mantras" que cubren este tema:

Explícito es mejor que implícito.

y

Los espacios de nombres son una gran idea, ¡hagamos más de ellos!

Existe una convención para nombrar e importar módulos que se puede encontrar en la Guía de estilo de Python (PEP 8).

La razón principal por la que no existe tal convención para prefijar constantemente los nombres de sus módulos en un estilo Java, es porque con el tiempo terminará con una gran cantidad de repeticiones en su código que realmente no necesitan estar allí.

Uno de los problemas con Java es que te obliga a repetirte constantemente. Hay un montón de repetitivo que va en el código Java que simplemente no es necesario en Python. (Getters / setters es un buen ejemplo de eso.)

Los espacios de nombres no son un problema tan grande en Python porque puedes darles un alias a los módulos al importarlos. Como:

import com.company.actualpackage as shortername

Por lo tanto, no solo puede crear o manipular el espacio de nombres dentro de sus programas, sino que también puede crear sus propios alias para guardar pulsaciones de teclas.


Una actualización para cualquiera que venga a buscar esto:

A partir de 2012, PEP 423 aborda esto. PEP 8 toca el tema brevemente, pero solo para decir: todo en minúscula o guión bajo.

La esencia de esto: elija nombres memorables y significativos que no se hayan usado en PyPI.