[pyar] [Programacion] Símbolo \

[Matias Graña]

2012/3/13 Sebastian Torres <softmindfreak en gmail.com>:
> Tal cual, se hace para mejorar la experiencia de lectura que puedas tener
> vos o algun otro programador.
> Generalmente todas las convenciones de cogido (en python y otros lenguajes)
> son para eso.
> Por ejemplo, tenes la convencion de los Docstrings:
>
> http://www.python.org/dev/peps/pep-0257/

Sí, claro, entiendo que se hagan estas convenciones. Apunto
específicamente a ésta, que me resulta fea.


> El 12 de marzo de 2012 22:40, Diego Sarmentero <diego.sarmentero en gmail.com>
> escribió:
>>
>> Es mejor hacerlo despues del operador, porque cuando estas leyendo el
>> código salta a SIMPLE VISTA de que es algo que continua en la linea de
>> abajo, si dejas algo como:
>>
>> if (x > 5) and value \
>>
>> "value" podria ser en si mismo un valor de tipo booleano o algo que se
>> esta evaluando en esa linea, en cambio:
>>
>> if (x > 5) and value != \
>>
>> SABES a muy simple vista que eso que venis leyendo sigue abajo y va a
>> ser comparado con ... y te permite seguir en tu cabeza de forma más
>> fácil la idea.
>>
>> Así lo veo yo al menos.

Es un buen ejemplo, aunque en ese caso el corte yo lo haría en el and,
y no en el !=.
El ejemplo que tengo en la cabeza es algo como

variable = un_termino_largo_de_calcular_que_incluye_llamadas_a_funciones \
    + otro_termino_largo \
    - otro_termino_tambien_larguito

Para mí eso de arriba es más fácil de entender de un vistazo que

variable = un_termino_largo_de_calcular_que_incluye_llamadas_a_funciones + \
    otro_termino_largo - \
    otro_termino_tambien_larguito

donde los operadores se pierden de vista. O mi cerebro parsea mal?

Matías