¿Por qué Python pep-8 recomienda espacios en lugar de pestañas para la sangría?

Veo en Stack Overflow y PEP 8 que la recomendación es usar espacios solo para sangría en programas Python. Puedo entender la necesidad de una sangría constante y he sentido ese dolor.

¿Hay alguna razón subyacente para que se prefieran los espacios? Pensé que las pestañas eran mucho más fáciles de trabajar.

La respuesta se dio allí mismo en el PEP [ed: este pasaje fue editado en 2013 ]. Yo cito:

La forma más popular de sangrar Python es solo con espacios.

¿Qué otra razón subyacente necesitas?

Para decirlo sin rodeos: Considere también el alcance de la PEP como se indica en el primer párrafo:

Este documento ofrece convenciones de codificación para el código de Python que comprende la biblioteca estándar en la distribución principal de Python.

La intención es hacer que todo el código que va en la distribución oficial de Python sea formateado consistentemente (espero que podamos estar de acuerdo en que esto es universalmente Good Thing ™).

Dado que la decisión entre espacios y pestañas para un programador individual es a) realmente una cuestión de gustos yb) se maneja fácilmente por medios técnicos (editores, guiones de conversión, etc.), existe una forma clara de finalizar toda discusión: elija uno .

Guido fue el que eligió. Ni siquiera tuvo que dar una razón, pero aún así lo hizo al referirse a datos empíricos.

Para todos los demás propósitos, puede tomar esta PEP como una recomendación, o puede ignorarla: su elección, la de su equipo o la de sus líderes de equipo.

Pero si puedo darte un consejo: no los mezcles ;-) [ed: Mezclar pestañas y espacios ya no es una opción].

Bueno, bueno, parece que todos están fuertemente predispuestos hacia los espacios. Yo uso pestañas exclusivamente. Sé muy bien por qué.

Las pestañas son en realidad una invención genial, que vino después de los espacios. Le permite sangrar sin presionar espacio millones de veces o usar una pestaña falsa (que produce espacios).

Realmente no entiendo por qué todos discriminan el uso de pestañas. Es muy parecido a que las personas mayores discriminan a las personas más jóvenes por elegir una tecnología más nueva y eficiente y se quejan de que la marcación por pulsos funciona en todos los teléfonos , no solo en estos nuevos y elegantes. "La marcación por tonos no funciona en todos los teléfonos, por eso está mal".

¿Tu editor no puede manejar las pestañas correctamente? Bueno, consigue un editor moderno . Podría ser un maldito tiempo, ahora estamos en el siglo XXI y el tiempo en que un editor era una pieza de software complicada de alta tecnología ha pasado hace mucho tiempo. Ahora tenemos toneladas y toneladas de editores para elegir, todos ellos que admiten pestañas muy bien. Además, puede definir cuánto debería ser una pestaña, algo que no puede hacer con espacios. ¿No puedes ver las pestañas? ¿Qué es eso para una discusión? Bueno, ¡tampoco puedes ver espacios!

¿Puedo ser tan valiente como para sugerir conseguir un mejor editor? ¿Uno de estos de alta tecnología, que se lanzaron hace unos 10 años, que muestran personajes invisibles ? (sarcasmo apagado)

El uso de espacios provoca mucho más trabajo de borrado y formateo. Es por eso que (y todas las demás personas que saben esto y están de acuerdo conmigo) usan pestañas para Python.

Mezclar pestañas y espacios es un no-no y ningún argumento al respecto. Eso es un desastre y nunca puede funcionar.

Personalmente, no estoy de acuerdo con los espacios sobre las pestañas. Para mí, las pestañas son un carácter / mecanismo de diseño de documentos, mientras que los espacios son para contenido o delineación entre comandos en el caso del código.

Tengo que estar de acuerdo con los comentarios de Jim de que las pestañas no son realmente el problema, son las personas y cómo quieren mezclar pestañas y espacios.

Dicho esto, me obligué a usar espacios por convenio. Valoro la coherencia sobre la preferencia personal.

La razón de los espacios es que las pestañas son opcionales. Los espacios son el mínimo común denominador real en la puntuación.

Cada editor de texto decente tiene un "reemplazar pestañas con espacios" y muchas personas lo usan. Pero no siempre.

Si bien algunos editores de texto pueden reemplazar una serie de espacios con una pestaña, esto es realmente raro.

Línea de fondo . No te puedes equivocar con los espacios. Usted puede ir mal con pestañas. Por lo tanto, no use pestañas y reduzca el riesgo de errores.

El problema con las pestañas es que son invisibles y las personas nunca pueden ponerse de acuerdo sobre el ancho de las pestañas. Cuando mezcle pestañas y espacios, y configure tabstops en algo que no sea Python (que usa tabstops cada 8 espacios) verá el código en un diseño diferente al que Python lo ve. Y debido a que el diseño determina los bloques, verá una lógica diferente. Conduce a errores sutiles.

Si insiste en desafiar a PEP 8 y ​​usar pestañas, o peor, mezclar pestañas y espacios, al menos siempre ejecute python con el argumento '-tt', lo que hace una sangría inconsistente (a veces una pestaña, a veces un espacio para la misma sangría nivel) un error. Además, si es posible, configure su editor para que muestre las pestañas de manera diferente. Pero realmente, el mejor enfoque es no usar pestañas, punto.

Los principales problemas con la sangría se producen cuando se mezclan pestañas y espacios. Obviamente, esto no le dice cuál debe elegir, pero es una buena razón para recomendar una, incluso si la elige lanzando una moneda.

Sin embargo, en mi humilde opinión, hay algunas razones menores para favorecer los espacios sobre las pestañas:

• Diferentes herramientas A veces, el código se muestra fuera del editor de un programador. P.ej. publicado en un grupo de noticias o foro. Los espacios generalmente funcionan mejor que las pestañas aquí: en todas partes los espacios se destrozarían, las pestañas también, pero no al revés.

• Los programadores ven la fuente de manera diferente. Esto es profundamente subjetivo: es el principal beneficio de las pestañas o una razón para evitarlas dependiendo de qué lado esté. En el lado positivo, los desarrolladores pueden ver la fuente con su sangría preferida, por lo que un desarrollador que prefiera sangría de 2 espacios puede trabajar con un desarrollador de 8 espacios en la misma fuente y aún así verlo como quiera. La desventaja es que esto tiene repercusiones: a algunas personas les gusta el espacio 8 porque da una respuesta muy visible de que están demasiado anidadas, es posible que vean el código verificado por el penetrador 2 que se ajusta constantemente en su editor. Hacer que todos los desarrolladores vean el código de la misma manera conduce a una mayor consistencia en las longitudes de línea y también a otros asuntos.

• Sangría de línea continua. A veces desea sangrar una línea para indicar que se transporta desde la anterior. p.ej.

  def foo():
      x = some_function_with_lots_of_args(foo, bar, baz,
                                          xyzzy, blah)

  Si usa pestañas, no hay forma de alinear esto para las personas que usan diferentes pestañas en su editor sin mezclar espacios y pestañas. Esto efectivamente mata el beneficio anterior.

Obviamente, este es un tema profundamente religioso, con el cual la programación está plagada. El problema más importante es que debemos elegir uno, incluso si ese no es el que usted prefiere. A veces pienso que la mayor ventaja de una sangría significativa es que al menos nos ahorramos la colocación de aparatos ortopédicos.

También vale la pena leer este artículo de Jamie Zawinski sobre el tema.

Tenga en cuenta que el uso de pestañas confunde otro aspecto de PEP 8:

Limite todas las líneas a un máximo de 79 caracteres.

Digamos, hipotéticamente, que usas un ancho de tabulación de 2 y yo uso un ancho de tabulación de 8. Escribes todo tu código para que tus líneas más largas alcancen 79 caracteres, luego empiezo a trabajar en tu archivo. Ahora tengo un código difícil de leer porque (como dice el PEP):

El ajuste predeterminado en la mayoría de las herramientas interrumpe la estructura visual del código.

Si todos usamos 4 espacios, SIEMPRE es lo mismo. Cualquiera cuyo editor pueda admitir un ancho de 80 caracteres puede leer cómodamente el código. Nota: El límite de 80 caracteres es una guerra santa en sí misma, así que no empecemos eso aquí.

Cualquier editor no sucky debe tener una opción para usar espacios como si fueran pestañas (tanto insertar como eliminar), por lo que realmente no debería ser un argumento válido.

La respuesta a la pregunta es: PEP-8 quiere hacer una recomendación y ha decidido que, dado que los espacios son más populares, recomendará espacios en lugar de pestañas.

Notas sobre PEP-8

PEP-8 dice 'Use 4 espacios por nivel de sangría'.
Está claro que esta es la recomendación estándar.

"Para el código realmente antiguo que no desea estropear, puede continuar usando pestañas de 8 espacios".
Está claro que hay ALGUNAS circunstancias cuando se pueden usar pestañas.

"Nunca mezcle pestañas y espacios".
Esta es una clara prohibición de mezclar, creo que todos estamos de acuerdo en esto. Python puede detectar esto y, a menudo, se ahoga. El uso del argumento -tt lo convierte en un error explícito.

'La forma más popular de sangrar Python es solo con espacios. La segunda forma más popular es solo con pestañas.
Esto establece claramente que ambos se usan. Para ser ultra claro: nunca debe mezclar espacios y pestañas en el mismo archivo.

'Para proyectos nuevos, solo se recomiendan espacios en lugar de pestañas'.
Esta es una recomendación clara y fuerte, pero no una prohibición de pestañas.

No puedo encontrar una buena respuesta a mi propia pregunta en PEP-8. Uso pestañas, que he usado históricamente en otros idiomas. Python acepta fuente con uso exclusivo de pestañas. Eso es lo suficientemente bueno para mí.

Pensé en intentar trabajar con espacios. En mi editor, configuré un tipo de archivo para usar espacios exclusivamente, por lo que inserta 4 espacios si presiono tab. Si presiono la pestaña demasiadas veces, ¡tengo que eliminar los espacios! Arrgh! ¡Cuatro veces más eliminaciones que pestañas! Mi editor no puede decir que estoy usando 4 espacios para las sangrías (aunque un editor AN podría hacer esto) y obviamente insiste en eliminar los espacios de uno en uno.

¿No se le podría decir a Python que considere que las pestañas son n espacios cuando sus sangrías de lectura? Si pudiéramos acordar 4 espacios por sangría y 4 espacios por pestaña y permitir que Python acepte esto, entonces no habría problemas.
Deberíamos encontrar soluciones win-win para los problemas.

Siempre he usado pestañas en mi código. Dicho esto, recientemente encontré una razón para usar espacios: cuando desarrollé en mi tableta de internet Nokia N900, ahora tenía un teclado sin una tecla de tabulación. Esto me obligó a copiar y pegar pestañas o reescribir mi código con espacios. Me he encontrado con el mismo problema con otros teléfonos. Por supuesto, este no es un uso estándar de Python, sino algo a tener en cuenta.

JWZ lo dice mejor :

Cuando [las personas] leen el código, y cuando terminan de escribir el código nuevo, les importa cuántas columnas de pantalla tiende a sangrar el código cuando se abre un nuevo alcance (o sexpr, o lo que sea) ...

... Mi opinión es que la mejor manera de resolver los problemas técnicos es ordenar que el carácter ASCII # 9 TAB nunca aparezca en los archivos del disco: programe su editor para expandir las TAB a un número apropiado de espacios antes de escribir las líneas en el disco. ..

... Esto supone que nunca usa pestañas en lugares donde son realmente significativas, como en cadenas o constantes de caracteres, pero nunca hago eso: cuando importa que sea una pestaña, siempre uso '\ t' en su lugar.

Dado que Python se basa en la sangría para reconocer la estructura del programa, se requiere una forma clara de identificar la ideación. Esta es la razón para elegir espacios o pestañas.

Sin embargo, Python también tiene una fuerte filosofía de tener solo una forma de hacer las cosas, por lo tanto, debe haber una recomendación oficial para una forma de sangrar.

Tanto los espacios como las pestañas plantean desafíos únicos para que un editor los maneje como sangría. El manejo de las pestañas en sí no es uniforme en todos los editores o incluso en la configuración del usuario. Como los espacios no son configurables, plantean la opción más lógica, ya que garantizan que el resultado se verá igual en todas partes.

La ventaja más significativa que puedo decir de los espacios sobre las pestañas es que muchos programadores y proyectos usan un número establecido de columnas para el código fuente, y si alguien comete un cambio con su tabulación establecida en 2 espacios y el proyecto usa 4 espacios como Las pestañas largas serán demasiado largas para la ventana del editor de otras personas. Estoy de acuerdo con que las pestañas son más fáciles de trabajar, pero creo que los espacios son más fáciles para la colaboración, lo cual es importante en un gran proyecto de código abierto como Python.

Puedes tener tu pastel y comértelo. Configure su editor para expandir las pestañas en espacios automáticamente.

(Eso estaría :set expandtaben Vim.)

Supongo que la mayoría de los editores de texto de Linux hacen que los valores predeterminados se vean ridículamente grandes por defecto. No puedo pensar en ninguna otra buena razón para usar espacios sobre pestañas.

Además de todas las otras razones ya mencionadas (consistencia, nunca mezclar espacios y pestañas, etc.), creo que hay algunas razones más para que la convención de 4 espacios tenga en cuenta. Estos solo se aplican a Python (y tal vez a otros lenguajes donde la sangría tiene significado). Las pestañas pueden ser mejores en otros idiomas, según las preferencias individuales.

1. Si un editor no muestra pestañas (lo que sucede, dependiendo de la configuración, en bastantes), otro autor podría suponer que su código usa 4 espacios, b / c casi todo el código de Python que está disponible públicamente lo hace; si ese mismo editor tiene un ancho de pestaña de 4, pueden suceder cosas desagradables, al menos, esa persona pobre perderá tiempo por un problema de sangrado que habría sido muy fácil de evitar si se apega a la convención. Entonces, para mí, la razón número uno es evitar errores con coherencia.

2. Replanteando la pregunta de cuál es mejor, pestañas o espacios, uno debería preguntarse cuáles son las ventajas de las pestañas; He visto muchas publicaciones que elogian las pestañas, pero pocos argumentos convincentes para ellas; buenos editores como emacs, vi (m), kate, ... hacen una sangría adecuada dependiendo de la semántica de su código, incluso sin pestañas; los mismos editores se pueden configurar fácilmente para eliminar la sangría en el espacio de retroceso, etc.

3. Algunas personas tienen preferencias muy fuertes cuando se trata de su libertad para decidir el aspecto / diseño del código; otros valoran la coherencia sobre esta libertad. Python reduce drásticamente esta libertad al dictar que la sangría se usa para bloques, etc. Esto puede verse como un error o una característica, pero de alguna manera viene con la elección de Python. Personalmente, me gusta esta coherencia: al comenzar a codificar en un nuevo proyecto, al menos el diseño está cerca de lo que estoy acostumbrado, por lo que es bastante fácil de leer. Casi siempre.

4. El uso de espacios para la sangría permite "trucos de diseño" que pueden facilitar la comprensión del código; algunos ejemplos de estos se enumeran en PEP8; p.ej.

   foo = long_function_name(var_one, var_two,
                            var_three, var_four)
   
   # the same for lists
   a_long_list = [1,
                  2,
                  # ...
                  79]
   
   # or dictionaries
   a_dict = {"a_key": "a_value",
             "another_key": "another_value"}

   Por supuesto, lo anterior también se puede escribir muy bien como

   foo = long_function_name(
       var_one, var_two,
       var_three, var_four)
   
   # the same for lists
   a_long_list = [
       1,
       2,
       # ...
       79]
   
   # or dictionaries
   a_dict = {
       "a_key": "a_value",
       "another_key": "another_value"}

   Sin embargo, este último toma más líneas de código y a veces se argumenta que menos líneas son mejores (b / c obtienes más en una sola pantalla). Pero si le gusta la alineación, los espacios (preferiblemente asistidos por un buen editor) le dan, en cierto sentido, más libertad en Python que las pestañas. [Bueno, supongo que algunos editores te permiten hacer lo mismo con pestañas;) - pero con espacios, todos lo hacen ...]

5. Volviendo al mismo argumento que todos los demás hacen: PEP 8 dicta (ok, lo recomienda) espacios. Si viene a un proyecto que usa solo pestañas, por supuesto, tiene pocas opciones. Pero debido al establecimiento de las convenciones PEP 8, casi todos los programadores de Python están acostumbrados a este estilo. Esto hace que sea mucho más fácil encontrar un consenso sobre un estilo que sea aceptado por la mayoría de los programadores ... y de lo contrario sería muy difícil lograr que las personas acuerden el estilo.

6. Las herramientas que ayudan a imponer el estilo generalmente conocen PEP 8 sin esfuerzo adicional. Esa no es una gran razón, pero es bueno que las cosas funcionen ~ fuera de la caja.

El problema universal con las pestañas es que se pueden representar de manera diferente en un entorno diferente.
En un editor dado, una pestaña puede tener 8 espacios o 2.
En algunos editores, puede controlar esto, mientras que en otros no.

Otro problema con las pestañas es cómo se representan en la salida impresa. Creo que la mayoría de las impresoras interpretan una pestaña como 8 espacios.

Con espacios, no hay duda. Todo se alineará según lo previsto por el autor.

Sobre la discusión entre Jim y Thomas Wouters en los comentarios.

El problema era ... dado que el ancho de las pestañas y los espacios pueden variar, y dado que los programadores no pueden ponerse de acuerdo sobre ninguno de los dos, ¿por qué las pestañas tienen la culpa?

Estoy de acuerdo con Jim en eso: las pestañas NO son malas en sí mismas. Pero hay un problema...

Con espacios puedo controlar cómo se ve "MI PROPIO CÓDIGO" en CADA editor del mundo. Si uso 4 espacios, no importa en qué editor abra mi código, tendrá la misma distancia desde el margen izquierdo. Con las pestañas, estoy a merced de la configuración del ancho de las pestañas para el editor, incluso para MI PROPIO CÓDIGO. Y eso no me gusta.

Entonces, si bien es cierto que incluso los espacios no pueden garantizar la coherencia, al menos le brindan más control sobre el aspecto de su PROPIO código en todas partes, algo que las pestañas no pueden.

Creo que NO es la consistencia en los programadores que escriben el código, sino la consistencia en los editores que muestran ese código, lo que hace que los espacios sean más fáciles de lograr (e imponer).