“” .Join (reversed (val)) vs val … ¿cuál es pythonic?

Entonces, de acuerdo con el Zen de PythonExplícito es mejor que implícito … Lo escaso es mejor que lo denso … La legibilidad cuenta … pero nuevamente, Flat es mejor que nested … ¿Entonces cuál es pythonic ?

val = "which is pythonic?" print("".join(reversed(val))) 

o

 print(val[::-1]) 

Solo soy un progtwigdor de Java que está aprendiendo Python, por lo que me parece interesante este material python ya que no hay analógico en el mundo de Java AFAIK.

Related of "“” .Join (reversed (val)) vs val … ¿cuál es pythonic?"

Mi esposa Anna ha apodado x[::-1] “la sonrisa marciana”: me inclino ante ella (y su larga experiencia en entrenamiento y estudios, y estudios en psicología humana), cuando se trata de juzgar lo que es fácil y natural. para la mayoría de la gente, y ella ama absolutamente el smiley marcial. “Solo hay que caminar hacia atrás”: ¡cuánto más directo y con más abstracción que la especificación detallada de “revertirlo y luego unirlo”!

Además, python -mtimeit menudo es un buen juez de lo que es Pythonic: los principales Pythonistas, a lo largo de los años, han tendido a optimizar lo que más a menudo necesitaban y utilizaban, por lo que una diferencia de rendimiento muy importante le dice qué “va con el grano” del lenguaje y sus mejores practicantes. Y por ese puntaje, el smiley marciano supera a las especificaciones detalladas de las manos …:

 $ python -mtimeit '"".join(reversed("hello there!"))' 100000 loops, best of 3: 4.06 usec per loop $ python -mtimeit '"hello there!"[::-1]' 1000000 loops, best of 3: 0.392 usec per loop 

¡Las diferencias de rendimiento de orden de magnitud simplemente no dejan mucho espacio para la duda!

El segundo (en mi opinión) es más Pythonic, ya que es más simple, más corto y más claro.

Para más información sobre qué es Pythonic , recomendaría The Zen of Python :

Lo bello es mejor que lo feo.
Explícito es mejor que implícito.
Lo simple es mejor que lo complejo.
Complejo es mejor que complicado.
Plano es mejor que nested.
Lo escaso es mejor que lo denso.
La legibilidad cuenta.
Los casos especiales no son lo suficientemente especiales para romper las reglas.
Aunque la practicidad supera a la pureza.
Los errores nunca deben pasar en silencio.
A menos que sea explícitamente silenciado.
Ante la ambigüedad, rechace la tentación de adivinar.
Debe haber una, y preferiblemente solo una, obvia forma de hacerlo.
Aunque esa forma puede no ser obvia al principio a menos que seas holandés.
Ahora es mejor que nunca.
Aunque nunca es a menudo mejor que ahora.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es fácil de explicar, puede ser una buena idea.
Los espacios de nombres son una gran idea, ¡hagamos más de ellos!

En mi opinión, su segundo ejemplo satisface estos principios:

Lo bello es mejor que lo feo.
Lo simple es mejor que lo complejo.
Lo escaso es mejor que lo denso.
La legibilidad cuenta.

Con una cadena, como usted tiene, me gustaría ir con la primera opción, ya que deja claro que el resultado que desea es una cadena. Para una lista u otro iterable / slicable, me gustaría ir con el segundo.

Un beneficio adicional del primer formulario es que funcionará si val no es realmente una cadena, sino algún otro tipo de caracteres (por ejemplo, un generador de algún tipo). En algunos casos, esto hace una gran diferencia.

Primero, si eres un principiante, no te preocupes por lo que es más pythonico o no. Esto huele a guerras de lenguaje, y eventualmente encontrarás tu propia opinión de todos modos. Simplemente use la forma en que usted cree que es más legible / más simple para usted y encontrará la luz, creo.

Dicho esto, estoy de acuerdo con la excelente respuesta de Alex (ya que siempre tiene razón) y agregaría un comentario adicional sobre por qué debería preferir el segundo método: el primero solo funcionará correctamente si val es una cadena.