[pyar] Nombrando clases en Python (convenciones)

[fisa]

Alguna vez he tenido ese debate dentro de mi cabeza, y me decidí por esto:

* Si es una cosa que se va a usar desde fuera de mi lib/módulo/app,
prefiero ponerle a la cosa (clase, función) un nombre descriptivo en
sí mismo, y no un nombre que para entenderlo deba además mirar el
nombre del módulo.
Podrá haber un poco de redundancia entre el nombre del módulo y el de
la cosa, pero eso se ve solo en la linea del import y no jode. En caso
contrario podés estar poniendo un nombre que después en el contexto de
uso de esa cosa, no es lo suficientemente explícito. Ej: encontrarte
en una app web con una línea de código que dice "s = Server()", y que
no sabés realmente qué hace si no mirás de dónde fue importado Server.

* Si es algo que solo se va a usar internamente en mi lib/módulo/app,
entonces no me jode poner un nombre más corto si es obvio dentro de
ese contexto. Por ejemplo, dentro de una lib de smtp si hay una clase
*interna* (no pensada como para que alguien la importe desde fuera)
que se llama Server, puede que sea lo suficientemente obvio para quien
esté manteniendo el código de la lib en sí. Pero again, solo si no es
algo pensado para ser usado desde fuera.

Saludos!


El día 7 de octubre de 2013 18:58, Hernan Grecco
<hernan.grecco en gmail.com> escribió:
> Hola,
>
> Hace un tiempo en una reunión de café, se armó una discusión acerca de
> cómo nombrar clases en Python. Quería tirar el tema a la lista para
> ver si hay alguna opinión mayoritaria o algún argumento contundente.
>
> Algunos proponían nombrar las clases de forma descriptiva. Hago un
> ejemplo con dos módulos ficticios que definen servidores/clientes para
> ftp y http.
>
> En ftp.py definis FTPServer
> En http.py definis HTTPServer
>
> y después lo usas:
>
> from ftp import FTPServer
> from http import HTTPServer
>
> f = FTPServer()
> h = HTTPServer()
>
> A favor:
> - similar a como se hace en la standard library
> - nombres de las clases independientes del contexto (lease modulo)
> En contra:
> - nombres largos, un poco repetitivos, sobre todo cuando se los usa en
> el mismo modulo (ej. usar FTPServer dentro de ftp.py)
> - puede volverse molesto nombrar clases derivadas de forma descriptiva.
>
> Otros proponían algo mas similar a lo que hace google go:
>
> En ftp.py definis Server
> En http.py definis Server
>
> y después lo usas:
>
> import ftp
> import http
>
> f = ftp.Server()
> h = http.Server()
>
> a favor:
> - nombres cortos y claros
> en contra:
> - requiere un lookup adicional (lo cual no parece ser mayor problema a
> menos que se llame muchas veces)
>
> Opiniones?
>
> Hernán
> Pd.- Esta claro que usando `as` puede pasarse de uno a otro fácilmente
> pero  las clases se usan mayoritariamente como son definidas.
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar



-- 
fisa  -  Juan Pedro Fisanotti