estilo, formatear el operador de corte

PEP 8 no menciona el operador de corte. Desde mi entendimiento, a diferencia de otros operadores, no debería estar rodeado de espacios en blanco.

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

¿Se mantiene esto cuando se usan expresiones complejas, es decir, cuál se considera mejor estilo?

      1. spam [jamón (66) // 3: 44 + huevos ()]
      2. spam [jamón (66) // 3: 44 + huevos ()]
      3. spam [jamón (66) // 3: 44 + huevos ()]
      4. algo mas?

Como ya mencionó, PEP8 no menciona explícitamente el operador de división en ese formato, pero el spam[3:5] es definitivamente más común y, en mi opinión, más legible.

Si pep8 checker es algo para pasar, el espacio anterior : marcará hacia arriba

 [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 solo debido a que asume : ser el operador para definir un dict literal y no se espera espacio antes que el operador. spam[3: 44] pasa por esa razón, pero eso no parece correcto.

En ese conteo, me quedo con el spam[3:44] .


Las operaciones aritméticas anidadas son un poco más complicadas. De sus 3 ejemplos, solo el segundo pasa la validación de 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 que todo lo anterior es difícil de analizar a simple vista.

Por legibilidad y cumplimiento con PEP8, personalmente me gustaría ir por:

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

O para más operaciones de complicación:

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

Veo rebanar utilizado en PEP8:

     - Utilice '' .startswith () y '' .endswith () en lugar de cortar la cadena para verificar
       Para prefijos o sufijos.

       startswith () y endswith () son más limpios y menos propensos a errores.  por
       ejemplo:

         Sí: si foo.startswith ('bar'):

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

No lo llamaría definitivo, pero respalda tu (y mi) comprensión:

 spam[3:5] # OK 

En cuanto a cuál usar en la situación más compleja, usaría el # 3. No creo que el método sin espacios alrededor del : se vea bien en ese caso:

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

Si desea que : destaque más, no sacrifique el espacio entre operadores, agregue espacios adicionales a:

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

No usaría el # 1 porque me gusta el espaciado de los operadores, y el # 2 se parece mucho a la key: value del diccionario key: value syntax de key: value .

Yo tampoco lo llamaría un operador. Es una syntax especial para construir un objeto de slice ; también puede hacer

 spam[slice(3, 5)] 

Estoy de acuerdo con tu 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 propio operador de división, que divide la expresión en dos partes que deben ser analizadas (tanto por el lector humano como por el intérprete) por separado. Por lo tanto, mi intuición es que la consistencia con PEP 8 debe sacrificarse para resaltar el operador : ie. rodeándolo con espacios en blanco como en el ejemplo 3. La pregunta es si omitir los espacios en blanco dentro de los dos lados de la expresión para boost la legibilidad o no:

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

contra

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

Me parece 1. más rápido para analizar.