¿Cómo puedo aprender a escribir efectivamente el código Pythonic?

Descubrí que la mayoría de las personas tienen sus propias interpretaciones de lo que realmente significa ser "Pythonic". De Wikipedia:

  

Un neologismo común en la comunidad de Python es el pitón, que puede tener   una amplia gama de significados relacionados con el estilo del programa. Decir que el código es   Pythonic es decir que usa los lenguajes de Python bien, que es natural   o muestra fluidez en el idioma. Asimismo, decir de una interfaz o   Característica del idioma que es pythonic es decir que funciona bien con   Los modismos de Python, que se combinan bien con el resto del idioma.

     

En contraste, una marca de código unpythonic es que intenta escribir   El código C ++ (o Lisp, Perl o Java) en Python, es decir, proporciona una   transcripción en lugar de una traducción idiomática de formas de   otro idioma. El concepto de pythonicity está estrechamente ligado a   Filosofía minimalista de Python de legibilidad y evitando la   "Hay más de una forma de hacerlo" enfoque. Código ilegible o   Las expresiones idiomáticas incomprensibles son antípticas.

He encontrado que más veces que no, más ejemplos "pitónicos" en realidad se derivan de personas que intentan ser inteligentes con los modismos de Python y (de nuevo, más veces que no) hacen que su código sea virtualmente ilegible (que es no Pythonic).

Mientras te mantengas en las expresiones idiomáticas de Python y evites intentar usar los estilos C ++ (u otro lenguaje) en Python, estarás siendo Pythonic.

Como lo señala WorldEngineer, PEP8 es un buen estándar a seguir (y si usa VIM, hay complementos disponibles para el forro PEP8).

Realmente, al final del día, si tu solución funciona y no es absolutamente imposible de mantener y lenta, ¿a quién le importa? Más de las veces, su trabajo es hacer una tarea, no escribir el código pitónico más elegante posible.

Otra nota al margen (solo mi opinión, siéntete libre de votar por eso;): También encontré que la comunidad de Python está llena de una tonelada de ego (no la mayoría de las comunidades no son , solo es un poco más frecuente en comunidades como C y Python). Por lo tanto, combinar el ego con interpretaciones erróneas de ser "pitónico" tenderá a generar una gran cantidad de negatividad sin fundamento. Toma lo que lees de otros con un grano de sal. Cumplir con los estándares oficiales y la documentación y estarás bien.

Pythonic es codificar idiomáticamente en Python. Significa utilizar estructuras y formatos que funcionen bien para Python desde un punto de vista de programación, pero también desde un punto de vista de lectura de la comunidad. Es muy parecido a cómo K & R establece el estándar para el estilo de programación en C durante mucho tiempo. Esta guía muestra que debes codificar de forma idiomática en Python. Se hace referencia a PEP 8 en esa guía, así que probablemente vale la pena leerlo.

Escribir el código "Pythonic" IMHO está haciendo un uso efectivo de las funciones (V) HLL que proporciona el lenguaje. Como un ejemplo ubicuo,

x, y = 7, 'fuhrer'

Eso es muy Pythonic. Recuerdo cuando comencé a aprender C # después de meses de Python,

int x, y = 10, z;

de alguna manera me confundió, pero tardé un minuto en volver a mis raíces de C / C ++.

Otra forma de Pythonic es utilizando lambdas.

l = [1, 2, 3, 4, 5]
print(sorted(l, key=lambda x: -x))

realmente imprimirá l ordenado en orden descendente.

Luego está el "tipografía de pato" muy usado, pero menos comprendido: si camina y habla como un pato, lo tratas como un pato. Esto se relaciona vagamente con las interfaces en otros idiomas OO.

También se utilizan métodos de programación funcional cuando sea aplicable, como el uso de mapear y reduce se consideran pitónicos.

Vi una respuesta publicada mientras escribía, y contiene un enlace agradable. PD: No es que tu conocimiento de Python sea limitado. ¡Puedo apostar a que Python no fue su primer idioma y, por lo tanto, (como la mayoría de nosotros los pitones), tendrá que aprender a ser "idiomático" con la serpiente! ¡Salud!

--> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

El código pitón es:

• legible
• Simple (lo más simple posible, pero no más simple)
• Bien pensado

Cada vez que he tratado de aprender un nuevo idioma, he encontrado ese código de lectura hecho por personas que saben el idioma como la palma de su mano, mirando hacia arriba / preguntando sobre cualquier cosa que parezca extraño, y luego tratando de imitar su lenguaje. El estilo es lo mejor que se puede hacer. Ejemplos:

En Python, ya que estamos en el tema, los ejemplos de Dive Into Python son increíblemente útiles para comenzar. Tienden a enseñar no solo lo básico de Python, sino a enfatizar realmente idiomático de Python.

Cuando aprendí D, ya que la documentación no era muy buena en ese momento porque el lenguaje era tan sangrante, aprendí leyendo el código en la biblioteca estándar, específicamente, algunos de las obras maestras de Andrei Alexandrescu .

Al aprender C ++, heredé una base de código de un programador de C ++ bastante bueno y aprendí mucho sobre la programación idiomática de C ++ de su insistencia en pasar los contenedores STL por referencia, etc.

En todos los idiomas, me parece que navegar por las preguntas de StackOverflow sobre el idioma y ver lo que las personas hacen para lograr cosas básicas ayuda.

Python no es Java puede darle algunos consejos útiles. No puedo decir más sin saber en qué tipo de problemas se encuentra, pero es un consejo muy concreto para los programadores que vienen de otro lenguaje (en este caso, específicamente, Java) sobre cómo hacer Python de manera diferente.

Alguien dijo parafrasear, para aprender qué es Pythonic, simplemente golpear un poco de código. No estoy de acuerdo con eso. Si te gusta escribir código altamente denso, eso no lo hace más Pythonic.

Una forma de ayudarlo a definir qué es Pythonic en lo que a usted respecta, pregúntese: "¿Por qué yo (es decir, usted) usaría el lenguaje Python?" ¿Qué te llama la atención?

Para mí es legibilidad y falta de compilación y código abierto (casi todo). Puedo descargar toneladas de bibliotecas y leer su código fuente con menos énfasis en las licencias que en muchos otros idiomas.

Para mí, Python es hermoso visualmente. Guido (el creador de Python) también me sigue demostrando, a través de sus respuestas en PEPS y discusiones) que sus decisiones sobre cómo hizo el lenguaje son superiores a mis propias ideas de cómo debería haber sido creado.

Para mí, un gran programador es alguien con habilidades de toma de decisiones muy informadas sobre qué camino tomar cuando se codifica. Para mí, Python ayuda a tomar esas decisiones rápidamente.

Al simplificar la sintaxis del código fuente permitiendo la tipificación duck en lugar de la conversión de tipos explícita, y la expectativa de que los programadores que revisen tu código "deben tener un buen comportamiento, los codificadores" llevan a algo que también llamo "Pythonic"

Así que hay dos lados de lo que es Pythonic. Uno es sintáctico, el otro es la práctica de. ¿Cómo explicar el lado más profundo de lo que es "Pythonic" ...?

En Python no es gran cosa hacer esto: alist = ['one', 'two', 'three \ n'] alist.append ((1234, 'Atuple'))

y la tupla se agregará a la lista sin preocuparse por los tipos de objetos. La parte de Pythonic no es que PUEDES hacer esto, sino que tu código debe ESPERAR esto y simplemente trabajar / adaptarse.

Lo que sea que funcione en el objeto -alist- debe escribirse con la idea de que algún otro codificador podría ingresar y agregar una no-cadena a la lista y que la adaptación del código fuente por el nuevo codificador no debería ser difícil de hacer. Ese es el beneficio de ducktype después de todo.

Compra un libro recomendado. Leerlo Debería darle una buena base para usar el lenguaje y en un mecanismo que debe cumplir con el estilo de la comunidad