estilo, formateando el operador de división

Question

PEP 8 no menciona el operador de división. Desde mi entender, a diferencia de otros operadores, no debería estar rodeado de espacios en blanco

spam[3:5] # OK 
spam[3 : 5] # NOT OK 

hace esto espera cuando el uso de expresiones complejas, es decir, que uno se considera mejor estilo

 
    1. spam[ham(66)//3:44+eggs()] 
    2. spam[ham(66) // 3: 44 + eggs()] 
    3. spam[ham(66) // 3 : 44 + eggs()] 
    4. something else? 

Answer 1

Como ya se ha mencionado, PEP8 no menciona explícitamente el operador de parte en ese formato, pero spam[3:5] es definitivamente más común y más fácil de leer en mi humilde opinión.

Si pep8 checker es cualquier cosa ir cerca, el espacio antes de : se marcará hasta

[me@home]$ pep8 <(echo "spam[3:44]") # no warnings 
[me@home]$ pep8 <(echo "spam[3 : 44]") 
/dev/fd/63:1:7: E203 whitespace before ':' 

... pero eso es sólo debido a que asume : de ser el operador para la definición de un diccionario literal y no hay espacio se espera antes que el operador. spam[3: 44] pasa por esa razón, pero eso simplemente no parece correcto.

En ese aspecto, me quedaría con spam[3:44].

---

Las operaciones aritméticas anidadas son un poco más complicadas. De sus ejemplos 3, sólo el segundo se pasa la validación PEP8:

[me@home]$ pep8 <(echo "spam[ham(66)//3:44+eggs()]") 
/dev/fd/63:1:13: E225 missing whitespace around operator 

[me@home]$ pep8 <(echo "spam[ham(66) // 3:44 + eggs()]") # OK 

[me@home]$ pep8 <(echo "spam[ham(66) // 3 : 44 + eggs()]") 
/dev/fd/63:1:18: E203 whitespace before ':' 

Sin embargo, me parece todo lo anterior difíciles de analizar por el ojo a primera vista.

Para facilitar la lectura y el cumplimiento de PEP8, yo personalmente voy por:

spam[(ham(66) // 3):(44 + eggs())] 

O para más operaciones de complicaciones:

s_from = ham(66) // 3 
s_to = 44 + eggs() 
spam[s_from:s_to] 

Answer 2

Estoy de acuerdo con su primer ejemplo. Para el último: PEP 20. La legibilidad cuenta La parte semánticamente más importante de su expresión de división compleja es el operador de división en sí, divide la expresión en dos partes que deben ser analizadas por separado (tanto por el lector humano como por el intérprete). Por lo tanto, mi intuición es que la consistencia con PEP 8 debería sacrificarse para resaltar el operador :, es decir. rodeándolo con espacios en blanco como en el ejemplo 3. La pregunta es si la omisión de los espacios en blanco dentro de los dos lados de la expresión a la legibilidad aumenta o no:

1. spam[ham(66)/3 : 44+eggs()] 

vs

2. spam[ham(66)/3 : 44 + eggs()] 

encuentro 1. rápido analizar.

Answer 3

veo SLICING utiliza en PEP8:

 
    - Use ''.startswith() and ''.endswith() instead of string slicing to check 
     for prefixes or suffixes. 

     startswith() and endswith() are cleaner and less error prone. For 
     example: 

     Yes: if foo.startswith('bar'): 

     No: if foo[:3] == 'bar': 

yo no llamaría a eso definitiva, sino que realiza copias de seguridad (y mi) la comprensión:

spam[3:5] # OK 

En cuanto a lo que a utilizar en la situación más compleja, usaría el n. ° 3. No creo que el no-espacios-en torno a-the-: método se ve bien en ese caso:

spam[ham(66)/3:44 + eggs()] # looks like it has a time in the middle. Bad. 

Si desea que el : para destacar más, no sacrificar el espaciamiento operador, añadir espacios adicionales a la ::

spam[ham(66)/3 : 44 + eggs()] # Wow, it's easy to read! 

no utilizaría # 1 porque me gusta el espaciamiento del operador, y # 2 se parece demasiado a la sintaxis key: value diccionario.

Yo tampoco lo llamaría un operador. Es una sintaxis especial para la construcción de un objeto slice - también se puede hacer

spam[slice(3, 5)]