[pyar] Nombrando clases en Python (convenciones)

[Hernan Grecco]

Hola,

Gracias fisa por los comentarios

> Alguna vez he tenido ese debate dentro de mi cabeza,

Esta bueno ver que no somos los únicos nerds!

Quisiera comentar algo acerca de una de las propuestas:

> * 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.

Yo usé poco Google Go, pero por lo que entiendo SIEMPRE se hace
referencia una clase por el nombre del paquete. En sintaxis Python,
esto significa que haces

>>> import ftp
>>> f = ftp.Server()

y no:

>>> from ftp import Server
>>> f = Server()

Esto significa que siempre tenes el nombre del módulo a mano cuando lo usas.


Hernán

> 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
> _______________________________________________
> 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