¿Qué es la documentación?

3/21
Recursos

Aportes 227

Preguntas 7

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

La documentación es la biblia de cualquier programador.
.
No puedes aspirar a aprender un lenguaje si no lees documentación. Sé que muchas personas se saltan eso porque piensan “ufff, es mucho texto, se ve feo”, etc. Pero es la documentación quien nos va a decir exactamente cómo funciona el lenguaje (y cualquier tecnología). No hay un solo desarrollador profesional que no lea documentación.
.
¡Y claro!, con esto no quiero decir que tengas que estar metido en la documentación siempre, pero quiero que sepas que la vas a consultar muchas veces cuando tengas problemas ❤️.
.
En ese paso de programador novato a programador profesional se encuentra aprender a consultar documentación, da el paso, no le temas a la documentación, es tu mejor amiga 😄.

Buenas, pase toda la documentacion a un pdf, asi la imprimo y la leo tranquilo. Les dejo el link, por si les interesa descargarla… saludos
[(https://drive.google.com/file/d/1dSYgA7Xonw1XLMcjrsMXSqDUWLlqi-57/view?usp=sharing)

❗Top 🔟 Beneficios de leer la documentacion de python📝
.
.

  1. Consultar informacion clara y directa
  2. Tener ejemplo de los mismos desarrolladores
  3. Referencias de todas las caracteristicas y funcionalidades en un solo lugar
  4. Conocer los nuevos features de nuevas actualizaciones
  5. Conocer el modo de empleo de versiones anteriores
  6. Aprender a manejar correctamente las herramientas
  7. Que contienen los modulos integrados dentro de python
  8. Como manejar los modulos
  9. Manejo y uso de frameworks
  10. Ser autodidacta

.
.
Link de documentacion: Documentacion python

Me gustaría compartirles una herramienta por si no les gusta leer la documentación desde la página o prefieren ir documentándose mientras programan 😉 les recomiendo que usen Kite que les brinda la documentación de cada función que escriban en su código con solo poner el cursor encima. Yo la ocupo bastante y me ayuda mucho mientras programo. 😁

Conocer la historia del lenguaje 🤩

Una parte que me llamó la atención fue la de historia y licencia. Por cierto, en mayo es la conferencia principal de la Python Software Foundation y aunque es de paga después se pueden ver muchas de las ponencias en Youtube.

También es muy importante conocer la guía de estilo, conocer y aplicar las buenas prácticas para que al trabajar con más personas podamos leer el código de manera sencilla y entendible. Esto se relaciona también con el Zen de Python que acabamos de ver.

Esta va a ser la primera documentación que voy a leer en mi vida.

Cuando queremos definir argumentos por defecto en una función, no debemos usar espacio entre el signo “=” y su nombre o su valor.

# Correct:
def complex(real, imag=0.0):
    return magic(r=real, i=imag)
# Wrong:
def complex(real, imag = 0.0):
    return magic(r = real, i = imag)

Descubrí que de hecho el Zen de Python es el PEP N°20 😃

https://www.python.org/dev/peps/pep-0020/

¿Romper la línea antes o después de un operador binario?
En cada lenguaje de programación me encuentro con el mismo problema: no saber dónde romper la línea de mi código. Generalmente lo hacía después, pero después de leer este articulito
https://www.python.org/dev/peps/pep-0008/#should-a-line-break-before-or-after-a-binary-operator

cambié de opinión. Romper la línea del código antes del operador facilita mucho la lectura del código. En Python se puede romper antes o después, siempre y cuando seamos consistentes con esta forma de romper el código 😄

Algo interesante de nuevo en python 3.9 es que ahora se pueden unir diccionarios con el operador | entonces en lugar de hacer
d1.update(d2)
puedes usar

d1 |= d2

ó

d3 = d1 | d2

en la documentacion pep 08 , forma correcta de importar.

correcta:

import os
import sys

inconrrecta:

import sys , os

¿Tabs o Espacio?

A criterio personal siempre he usado y preferido tab para organizar mi código, sin embargo, la documentación de Python dice que es preferible usar espacio para la sangría o indentación de ésta.

Intentaré hacer caso a la documentación y usar más el tab

Comentarios
Los comentarios que contradicen el código son peores que ningún comentario. ¡Siempre tenga la prioridad de mantener los comentarios actualizados cuando cambie el código!

Los comentarios deben ser oraciones completas. La primera palabra debe escribirse en mayúscula, a menos que sea un identificador que comience con una letra minúscula (¡nunca altere el caso de los identificadores!).

Los comentarios en bloque generalmente consisten en uno o más párrafos construidos a partir de oraciones completas, y cada oración termina en un punto.

Debe utilizar dos espacios después de un período de finalización de una oración en los comentarios de varias oraciones, excepto después de la oración final.

Asegúrese de que sus comentarios sean claros y fácilmente comprensibles para otros hablantes del idioma en el que está escribiendo.

Codificadores de Python de países que no hablan inglés: escriba sus comentarios en inglés, a menos que esté 120% seguro de que el código nunca será leído por personas que no hablen su idioma.

📑 La documentación es como un diccionario o manual de Python. Nos permitirá seguir buenas practicas.

Aquí les dejo el documento PEP 8 – Style Guide for Python Code en la versión de español

-PEP 8 - Spanish: https://recursospython.com/pep8es.pdf

Hola!

¿Sabían que google tiene su propia guía de estilos para Python? Les comparto aquí el link con la documentación Google Python Style Guide

Es común que las empresas usen estilos propios para escribir o desarrollar su código, esto permite crear un estándar entre todos los desarrolladores facilitando su lectura, comprensión y curva de aprendizaje 😁

Esto es un problema que muchas personas tienen (Tenemos).
Leer lo encontramos aburrido y nos cuesta aún más cuando son cosas “aburridas” pero para mi (Que odio leer cosas aburridas) ha sido todo un descubrimiento empezar a leer documentación. Cada línea te abre la puerta a más líneas y prácticamente se vuelve una adicción leer documentación para saber que más hay o que más puede hacer Python.

Lean documentación y verán incluso que estarán algunos pasos adelante a otros y podrán postular a trabajos mejores.

Saludos compañeros!

Yo uso Nvim para programar en python, y mi auto completado es Kite (esta disponible para otros editores de código). Lo uso porque me permite de manera rápida ir a la documentación de cualquier cosa, me provee ejemplos de como utilizar lo que estoy buscando sin yo tener que abrir el navegador es muy potente lo recomiendo bastante.
😃

La documentación de un lenguaje y leerla correctamente puede marcar la diferencia entre dar vueltas en google y ser ágil a la hora de programar.

Os recomiendo en serio ojear siempre la documentación de un lenguaje o una tecnología.

No digo que Google no sea una solución eficaz, al contrario, pero tener una idea de la documentación siempre va a ser útil 😃

Animo a todos!

No compare los valores booleanos con Verdadero o Falso usando ==:

# Correct:
if greeting:
# Wrong:
if greeting == True:

Peor:

# Wrong:
if greeting is True:

Esta aclaración me pareció muy importante para los programadores novatos que suelen cometer estos errores.

PEP, Python Enhancement Proposals

DESCUBRIMIENTO IMPORTANTE

¿Por qué las variables tienen underscore _ o doble underscore __ antes o después de su nombre?

De la guia de estilos PEP8:
_single_leading_underscore: weak “internal use” indicator. E.g. from M import * does not import objects whose names start with an underscore. APLICA CUANDO QUIERES QUE TU VARIABLES SOLO SEA USADA DENTRO DEL MÓDULO

single_trailing_underscore_: AGREGA EL _ AL FINAL SI QUIERES EVITAR CONFLICTOS CON PALABRAS RESERVADAS DE PYTHON

__double_leading_underscore: when naming a class attribute, invokes name mangling (inside class FooBar, __boo becomes _FooBar__boo; see below). APLICA CUANDO TU CLASE VA A SER HEREDADA Y NO QUIERES QUE EL ATRIBUTO SEA USADO EN LA SUBCLASE. AL AGREGAR EL DOBLE __ SE INVOCA EL ALGORITMO “MANGLING” PARA ALTERAR LA INVOCACIÓN DE LA SUBCLASE EN LA VARIABLE

Investigue un poco y encontré una herramienta llamada autopep8 y lo que hace es formatear nuestro código siguiendo las reglas de pep8. Espero les interese 😃

se instala con pip:
pip install autopep8
y luego con el siguiente comando se transforma nuestro archivo:
autopep8 --in-place --aggressive --aggressive <filename>

Dejo su documentación:
https://pypi.org/project/autopep8/
y la página en donde lo descubrí:
https://programmerclick.com/article/58171335885/

Yo leyendo sobre las convenciones para nombrar variables cuando derrepente:

Capitalized_Words_With_Underscores (ugly!) 😂

Resumen
|
La DOCUMENTACIÓN es fundamental para aprender cualquier lenguaje de programación, ya que nos ayuda a entender todas esas pequeñas piezas para que todo funcione correctamente. Recuerda que esta escrito en un lenguaje muy técnico.
|
La documentación de python esta en: https://docs.python.org/3/
|
NOTA: Recuerda revisar la versión que usas python3 --version ya que en cada versión se añaden o se corrigen funcionalidades.
|
PEP (propuestas de mejoras de python)
|
En el apartado PEPindex Nos indica como el lenguaje funciona y como se debería escribir de forma correcta. Todo lo relacionado a buenas practicas en la escritura del código (identacion, comentarios, nombres recomendados) lo encontramos en PEP8.
|
Bonus: en PEP20 esta el Zen de Python

**Lenguaje de maquina. **
Algo curioso que encontré en el glosario de la documentación de python es el interprete bytecode este es un código intermedio abstracto que el código máquina, en pocas palabras, es una traducción del lenguaje de alto nivel que es python a un lenguaje que logra entender directamente un circuito microprogramable algo así como la ISA (Instruction Set Architecture).
Quien tenga curiosidad de saber como se programa en bytes los invito a conocer la arquitectura MIPS
https://www.mips.com/products/architectures/mips32-2/

Soy muuuuuyyyy nuevo en esto de programar y la verdad la documentación me confunde. Yo prefiero siempre ver un video como estos, de una fuente confiable, que leer algo que no entiendo completamente. Para mí es más cómodo y efectivo buscar soluciones en google ya que dentro de esas mismas soluciones, muchas veces encuentro otros problemas que se pueden presentar y como resolverlos. Siento que aprendo más así.
Sin embargo, está chido saber gracias a la documentación de Python que la longitud de las líneas no debe de ser mayor a 79 caracteres.

Nombres para evitar

Nunca use los caracteres ‘l’ (letra minúscula ele), ‘O’ (letra mayúscula oh) o ‘I’ (letra mayúscula i) como nombres de variable de un solo carácter.

En algunas fuentes, estos caracteres son indistinguibles de los números uno y cero. Cuando tenga la tentación de usar ‘l’, use ‘L’ en su lugar.

En el PEP 8, sugieren evitar el uso de la L minúscula (‘l’), O mayúscula (‘O’) y la I mayúscula (I) cuando se trata de nombrar variables de un solo carácter. https://www.python.org/dev/peps/pep-0008/#names-to-avoid

Me parece bastante interesante la documentación, no sólo porque allí encontramos solución a nuestras dudas, sino también porque está en Inglés y así mejoramos esta skill
👾

¡Hola!
Los invito a usar Flake8 que es una herramienta para la aplicación de la guía de estilo, es muy útil y fácil de usar para los que quieran tener un código más limpio.

https://flake8.pycqa.org/en/latest/

Hola Team Platzi! 😄

Quiero complementar los cursos de Python con lo aprendido en el curso de Fundamentos de bases de datos y ganar más valor con cada curso.

Comparto 2 links, uno de la documentación de Python que comparte una librería para aplicar lenguaje SQL y nos pueda ayudar con el enlace de estas dos herramientas (Lenguajes).

https://dev.mysql.com/doc/connector-python/en/connector-python-tutorial-cursorbuffered.html

https://docs.python.org/3/library/persistence.html

A mí me pareció interesante que en Python se pueden nombrar variables de un montón de formas y en todos los cursos insisten en que es minúscula separada por guiones, a lo mejor los programadores Python se ven obligados a restringirse solos debido a tanta libertad del lenguaje (eso es lo que me parece curioso)

documentar es muy importante, rabajado en IBM me encontraba programas con 0 documentacion y es terrible tratar de interpretarlo todo solo a lectura

Yo estaba explorando y encontré algo que no sabía, en Python puedes trabajar con fracciones. Puedes hacer varias cosas como transformar decimales a fracciones. Presiona aquí para leer la documentación de las fracciones.

En todo el tiempo que llevo conociendo el PEP nunca había revisado más allá de los Meta-PEPs, fue sorprendente encontrar el Zen de Python e incluso divertido revisar el Tutorial de Coincidencia de patrones estructurales. La filosofía de Python siempre guarda algo con que sorprenderte.

La documentación es algo como un “manual de instrucciones”, donde se encuentra la explicación de cada aspecto del lenguaje /tecnología. Cualquier cosa sobre el funcionamiento del lenguaje.

La información de las documentaciones suele ser muy técnica y extendida, por lo que puede llegar a ser abrumador.

Esta explicación me pareció importante cuando estamos trabajando con potencias:
“Debido a que ** tiene una prioridad mayor que `-, -32 se interpretará como -(32), por lo tanto dará como resultado -9. Para evitar esto y obtener 9, puedes usar (-3)**2.”

Definitivamente la parte que más me llama la atención es el Tutorial. Debe complementar muy bien el aprendizaje ir leyendo lo que ves en un curso o video. Como dato adicional, un buen resumen de la documentación son los Apuntes de Majo, que explican de manera un poco más agradable los conceptos del lenguaje.

secrets.compare_digest(a, b)

Devuelve True si las cadenas a y b son iguales, de lo contrario False, de tal manera que se reduzca el riesgo de timing attacks.

RETO:
Comentarios muy importante su normativa:
"Los comentarios deben ser oraciones completas. La primera palabra debe escribirse en mayúscula, a menos que sea un identificador que comience con una letra minúscula (¡nunca altere el caso de los identificadores!).
Los comentarios en bloque generalmente consisten en uno o más párrafos construidos a partir de oraciones completas, y cada oración termina en un punto.
Debe utilizar dos espacios después de un período de finalización de una oración en los comentarios de varias oraciones, excepto después de la oración final.
Asegúrese de que sus comentarios sean claros y fácilmente comprensibles para otros hablantes del idioma en el que está escribiendo"
Respecto a los comentarios en línea
Utilice los comentarios en línea con moderación.
Un comentario en línea es un comentario en la misma línea que una declaración. Los comentarios en línea deben estar separados por al menos dos espacios de la declaración. Deben comenzar con un # y un solo espacio.
Los comentarios en línea son innecesarios y de hecho distraen si dicen lo obvio.
No hagas esto: x = x + 1 # Incremento x
Pero a veces, esto es útil: x = x + 1 # Compensa por borde

Siempre tuve la duda de si era mejor usar tabs o espacios, pero según el PEP-008, parece que da lo mismo a partir de Python, pero se tiene que respetar un solo patrón para todo el programa.

Me pareció interesante estas recomendaciones en el PEP 8. Siempre el criterio del programador es importante, incluso a la hora de aplicar un guideline .

In particular: do not break backwards compatibility just to comply with this PEP!

Some other good reasons to ignore a particular guideline:

  1. When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.

  2. To be consistent with surrounding code that also breaks it (maybe for historic reasons) – although this is also an opportunity to clean up someone else’s mess (in true XP style).

  3. Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code.

  4. When the code needs to remain compatible with older versions of Python that don’t support the feature recommended by the style guide.

Fuente: https://www.python.org/dev/peps/pep-0008/

Argumentos de función y método
Utilice siempre self para el primer argumento de los métodos de instancia.

Utilice siempre cls para el primer argumento de los métodos de clase.

Si el nombre de un argumento de función entra en conflicto con una palabra clave reservada, generalmente es mejor agregar un guión bajo al final en lugar de usar una abreviatura o una alteración ortográfica. Por tanto, class_ es mejor que clss . (Quizás sea mejor evitar tales choques usando un sinónimo).

La documentacion siempre me ayuda a validar las funcionalidades de un comando o instrucción. Me parece muy útil e importante que se cuente con ella.

Longitud máxima de la línea

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

Para bloques de texto largos y fluidos con menos restricciones estructurales (docstrings o comentarios), la longitud de la línea debe limitarse a 72 caracteres.

Lo que me pareció bastante interesante de la documentación de Python (toda ella es super útil) fue los Comos (HOWTOs) de Python.
Actualmente trabajo en el desarrollo de un aplicativo y hay un capítulo específico para logging. Lo voy a mirar con detenimiento.

Longitud máxima de la línea (según PEP8)

  • Limite todas las líneas de código a un máximo de 79 caracteres.
  • Para bloques de texto largos con menos restricciones estructurales (docstrings o comentarios), la longitud de la línea debe limitarse a 72 caracteres.

Limitar el ancho línea hace posible tener varios archivos abiertos uno al lado del otro y funciona bien cuando se utilizan herramientas de revisión de código que presentan las dos versiones en columnas adyacentes.

El “wrapping” predeterminado en la mayoría de los IDE interrumpe la estructura visual del código y lo hace más difícil de entender. Los límites se eligen para evitar que los editores ajusten el ancho de ventana establecido en 80.

Algunos equipos prefieren usar líneas más largas. Para un código mantenido exclusiva o principalmente por ese equipo se puede llegar al acuerdo de aumentar el límite de longitud de línea hasta 99 caracteres, siempre que los comentarios y las documentaciones sigan envueltos en 72 caracteres.

La biblioteca estándar de Python es conservadora y requiere limitar las líneas a 79 caracteres (y cadenas de documentación / comentarios a 72).

  • La forma preferida de envolver líneas largas es utilizando la continuación de línea implícita de Python entre paréntesis, corchetes y llaves.
  • Las líneas largas se pueden dividir en varias líneas ajustando las expresiones entre paréntesis. Estos deben usarse en lugar de usar una barra invertida () para la continuación de la línea.

Reto de Documentación - cbernacbr256 - 27/09/2021

luego de investigar mas a profundidad sobre la documentación encontré este video https://www.youtube.com/watch?v=4fkPKAnmUlQ , en cual me mostro como documentar una función en la consola

Esto me pareció valioso:

Las barras invertidas pueden ser apropiadas en ocasiones. Por ejemplo, las declaraciones largas y múltiples con - no pueden usar la continuación implícita, por lo que las barras diagonales inversas son aceptables:

con open ('/ ruta / a / algún / archivo / que / desea / leer') como archivo_1, \
     abrir ('/ ruta / a / algún / archivo / siendo / escrito', 'w') como archivo_2:
    file_2.write (file_1.read ())

Lo encontré por acá: Longitud Máxima de la línea - Python

Tienes razón, la documentación es bastante técnica, este apartado que adjunto lo he comprendido bastante bien por que en los cursos anteriores de la escuela de ciencias de datos ya nos lo habían explicado, también Freddy en el curso de programación básica lo explica varias veces, lo recomiendo un montón.


Se encuentra en el punto 3. Modelo de datos.

bytecode
Python source code is compiled into bytecode, the internal representation of a Python program in the CPython interpreter. The bytecode is also cached in .pyc files so that executing the same file is faster the second time (recompilation from source to bytecode can be avoided). This “intermediate language” is said to run on a virtual machine that executes the machine code corresponding to each bytecode. Do note that bytecodes are not expected to work between different Python virtual machines, nor to be stable between Python releases.

A list of bytecode instructions can be found in the documentation for the dis module.

Al realizar la indentación, generalmente yo presiono tab, y por lo que leo en el PEP 8 es mejor usar los 4 espacios y TAB sólo para mantener coherencia en el código, además de que no se permite una combinación de TAB y espacios.
😮

[Comunicación entre Js y Python] No lo busqué precisamente en la doc pero lo encontré por ahí. Vengo del frontend y me interesa mucho la forma de combinar estos dos lenguajes 👉 (https://es.ephesossoftware.com/articles/programming/how-to-get-python-and-javascript-to-communicate-using-json.html)

La documentación hace parte integral de los conceptos que debe tener el programador, pero en la actualidad python tiene una comunidad grande de colaboradores y es muy común encontrar tutoriales.

Me llamo mucho lo estético que se deben colocar los operadores, por eso es muy importante leer la documentación y tener un programa legible y ordenado

Método ** PYTHÓNICO **

Este lo encontré en el glosario y muestra algo interesante, la elegancia y sencillez del lenguaje

Algo que leí en la documentación sobre los números complejos:
a + bi = complex(real=a, imag=b)

Comentarios en la misma lineal

Tratar de usar los comentarios en una misma linea lo menos posible, sobre todo si es algo muy obvio

El comentario debe tener al menos dos espacios de la declaración a ejecutar y tener al menos un espacio después de la # para comentar

Ejemplo de caso a evitar

 x = x + 1                 # Incrementar x

Como se que muchos de nosotros no sabemos ingles o no tenemos tantos conocimientos como para leer la documentacion en esta pagina esta toda la documentacion en español (igual tenes que aprender ingles y leer en este idioma es un excelente ejercicio)
https://recursospython.com/pep8es.pdf

Les recomiendo leer la documentacion nos ayudara a evitar o resolver de una manera mas rapida algunos errores y asi poder ayudar a la comunidad.

La documentación de python es extensa y muy bien explicada en cada apartado.
Me intereso mucho el import math, hay muchas formulas y formulas que permitirian ressolver problemas matematicos o de calculos.

Mentira, siempre lean la documentación, es indispensable. Citando lo que dice Guido en el PEP8

" code is read much more often than it is written. "

Asi que para conocer a detalle hay que leer la documentación.

“”“Nomalemente no le prestaba atencion a la forma enque colocaba los operadores, la documentaciòn sugiere hacerlo de la siguiente manera, y la verdad se ve muy bien.”""

Tal como el profe, yo tampoco soy muy dada a buscar o leer documentacion como estas, por lo general busco es en chat, foros o escritos cortos de la experiencia de otros sin embargo reconozco que esta dicumentacion tiene cosas bastante interesantes como los estilos de python … aspecto super importantes si queremos ser reconocidos como profesionales…

Será una buena forma de practicar Inglés 😃

El pep 8

Python HOWTOs, esta seccion es super interesante para casos puntuales.

Python permite escribir programas compactos y legibles. Los programas en Python son típicamente más cortos que sus programas equivalentes en C, C++ o Java por varios motivos:
los tipos de datos de alto nivel permiten expresar operaciones complejas en una sola instrucción;
la agrupación de instrucciones se hace mediante indentación en vez de llaves de apertura y cierre;
no es necesario declarar variables ni argumentos.

Uno de los problemas que me hacia desistir cuando queria aprender JAVA era las llaves y punto y coma que necesita en el codigo, pero con Python las cosas son tan sencillas que ayuda muchisimo.

Estaba recordando de este libro que para mí es la mejor documentación en resumen, espero a alguien le sirva https://books.goalkicker.com/PythonBook/

La PEP 8 es como cuando aprendes el formato APA para escribir la tesis o un paper, no sabia que también existían ese tipo de guías para escribir código.

La identación correcta permite reconocer fácilmente el inicio y el final de cada argumento:

Correct:

Aligned with opening delimiter.

foo = long_function_name(var_one, var_two,
var_three, var_four)

Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.

def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)

Hanging indents should add a level.

foo = long_function_name(
var_one, var_two,
var_three, var_four)

Estaba haciendo un programilla para recordar el curso anterior que hacía bastante que no tocaba y bueno, acabé usando muchos if pero en la documentación he podido encontrar una solución mejor y más sencilla.
Os dejo una lectura sencilla de lo que había en la documentación y una nueva implementación en la versión 3.10 que vais a amar.
Las sentencias if, while y for implementan construcciones de control de flujo tradicionales. try especifica gestores de excepción o código de limpieza para un grupo de sentencias, mientras que las sentencias with permite la ejecución del código de inicialización y finalización alrededor de un bloque de código. Las definiciones de función y clase también son sentencias sintácticamente compuestas.

_Nuevo en la versión 3.10.

Algunos identificadores solo están reservados en contextos específicos. Estos se conocen como palabras clave suaves. Los identificadores match, case y _ pueden actuar sintácticamente como palabras clave en contextos relacionados con la declaración de coincidencia de patrones, pero esta distinción se realiza en el nivel del analizador, no cuando se tokeniza.

Como palabras clave suaves, su uso con la coincidencia de patrones es posible sin dejar de preservar la compatibilidad con el código existente que usa match, case y _ como nombres de identificadores._

El dilema interminable para varios.

Tabs or Spaces?
Spaces are the preferred indentation method.

Tabs should be used solely to remain consistent with code that is already indented with tabs.

Python disallows mixing tabs and spaces for indentation.

En lo personal prefiero tab por practicidad.

Siempre dejaba espacios en blanco innecesarios y siempre presentía que era incorrecto, ahora me queda más claro.

En el PEP 8 es importante resaltar este pedazo del texto.
Inmediatamente dentro de paréntesis, corchetes o llaves:

Correcto:

spam (jamón [1], {huevos: 2})

Incorrecto:

spam (jamón [ 1 ], { huevos: 2 } )
Entre una coma final y un paréntesis de cierre siguiente:

Correcto:

foo = (0,)

Incorrecto:

barra = (0, )
Inmediatamente antes de una coma, punto y coma o dos puntos:

Correcto:

si x == 4: imprime x, y; x, y = y, x

Incorrecto:

si x == 4 : imprime x , y ; x, y = y, x

Me pareció interesante el PEP 272 – API for Block Encryption Algorithms v1.0. La criptografía y los secretos siempre tendrán algo de misticismo que los hará interesantes a los ojos de cualquier programador.

Indicaciones para declarar variables y pasar argumentos
*

En lo personal no me imaginé que es una buena práctica tener líneas menores a 79 caracteres. Tampoco que es preferible usar espacios que tabulador (me va a costar dejar esta práctica) Pero en especial me llamó la atención esta convención de ordenar visualmente la jerarquía de operaciones:

Class Names
Class names should normally use the CapWords convention.

The naming convention for functions may be used instead in cases where the interface is documented and used primarily as a callable.

Note that there is a separate convention for builtin names: most builtin names are single words (or two words run together), with the CapWords convention used only for exception names and builtin constants.

La parte me llamo la atención fue justo al principio con esta frase:

One of Guido’s key insights is that code is read much more often than it is written.

Una de las observaciones clave de Guido es que el código se lee con mayor frecuencia de la que se escribe.

Curioso ya que en esta etapa en la que estamos muchos, estamos más pendiente de aprender a escribir código.

https://www.python.org/dev/peps/pep-0616/
Me pareció interesante este pep, hace referencia a opciones para remover sufijos y prefijos de una cadena.

Buenas! Algo que me llamó la atención dentro de la documentación de Python fue el tutor interactivo dentro de la guía para principiantes. Allí podemos encontrar diversos ejemplos de aplicación de conceptos propios del lenguaje.

Por ejemplo, la siguiente captura es la visualización de la ejecución de un programa en el que se aplica herencia.

El siguiente es el link al tutor.

https://pythontutor.com/visualize.html#mode=edit

Otra cosa interesante para mí fue ver que Python tiene un módulo para trabajar con números complejos. Soy estudiante de Ing. Electromecánica y este conjunto de números se utiliza para el análisis de circuitos eléctricos, entre muchísimas otras aplicaciones.

Link a la documentación

https://docs.python.org/3/library/cmath.html

Espero que les haya gustado mi aporte, saludos!

Nombres de funciones y variables
Los nombres de las funciones deben estar en minúsculas, con palabras separadas por guiones bajos según sea necesario para mejorar la legibilidad.

Los nombres de variables siguen la misma convención que los nombres de funciones.

Bloquear comentarios
Los comentarios de bloque generalmente se aplican a algunos (o todos) los códigos que los siguen, y están sangrados al mismo nivel que ese código. Cada línea de un comentario de bloque comienza con un # y un solo espacio (a menos que sea texto sangrado dentro del comentario).

Los párrafos dentro de un comentario de bloque están separados por una línea que contiene un solo # .
Comentarios en línea
Los comentarios en línea son innecesarios y, de hecho, distraen si dicen lo obvio. No hagas esto:

x = x + 1 # Incremento x
Pero a veces, esto es útil:

x = x + 1 # Compensar borde

Cadenas de documentación
"""Regresar un foobang

El plotz opcional dice que frobnicar al bizbaz primero.
""“
Para cadenas de documentación de una sola línea, mantenga el cierre “”” en la misma línea:

“”“Devolver un ex-loro”.""

De acuerdo a la documentación.
Usa el operador ‘is not’ preferiblemente que ‘not’. Ambas expresiones son funcionalmente identicas, la primera es mas facil de leer y por lo tanto preferida:
Ej:

Correct:

if foo is not None:

Wrong:

if not foo is None:

**Hay una seccion en la documentacion que se llama abriendo el apetito, en verdad es super genial hasta nos enseña porque Python se llama python, les dejo con la ultima parte. **

Por cierto, el lenguaje recibe su nombre del programa de televisión de la BBC «Monty Python’s Flying Circus» y no tiene nada que ver con reptiles. Hacer referencias sobre Monty Python en la documentación no sólo esta permitido, ¡sino que también está bien visto!

❗Top 🔟 Beneficios de leer la documentacion de python📝
.
.

Consultar informacion clara y directa
Tener ejemplo de los mismos desarrolladores
Referencias de todas las caracteristicas y funcionalidades en un solo lugar
Conocer los nuevos features de nuevas actualizaciones
Conocer el modo de empleo de versiones anteriores
Aprender a manejar correctamente las herramientas
Que contienen los modulos integrados dentro de python
Como manejar los modulos
Manejo y uso de frameworks
Ser autodidacta
.
.
Link de documentacion: Documentacion python

Comentarios en línea
Utilice los comentarios en línea con moderación.

Un comentario en línea es un comentario en la misma línea que una declaración. Los comentarios en línea deben estar separados por al menos dos espacios de la declaración. Deben comenzar con un # y un solo espacio.

Los comentarios en línea son innecesarios y, de hecho, distraen si dicen lo obvio. No hagas esto:

x = x + 1 # Incremento x
Pero a veces, esto es útil:

x = x + 1 # Compensa por borde

Pues al parecer hay un límite de 79 caracteres al programar en Python. Y de 72 si es que no empleamos ni comentarios ni cadenas de documentación

Revisando las buenas prácticas en Python encontré esto que lo recomendable es no pasarse de 79 carácteres por línea.

Les dejo esta guía para ponerse una línea que indique los 79 carácteres en VSCode:
1 - Vamos a configuracion > Area de trabajo > Y buscamos "Editor:Rulers"
2 - El primer resultado seguramente, le damos a "Editar en settings.json"
3 - Añadimos al final de todo estas 3 lineas:

    "editor.rulers": [
        
        79
    ],
    "workbench.colorCustomizations": {
        "editorRuler.foreground": "#ff333388"
    },

Para aquellos que no son expertos en inglás, aquí está el enlace de la documentación de Python en español:

https://python-docs-es.readthedocs.io/es/3.10/

Me llamo la atención un articulo que enseña las convenciones para nombrar en Python, esta en el PEP 8: https://www.python.org/dev/peps/pep-0008/#id32

Me pareció importante como muestran la forma y advierten el uso correcto e incorrecto de como comparar los valores boolean!!!

Don't compare boolean values to True or False using ==:

# Correct:
if greeting:
# Wrong:
if greeting == True:
Worse:

# Wrong:
if greeting is True:

Algo que me llamo la atención fueron los espacios. Dentro de los paréntesis no hay que dejarlos, ni cuando vas a abrir uno. Otra cosa es que a la hora de importar varias librerías no deberías colocarlas : import sys, cap, trul x. Debe ser una en cada reglón. Ej: import dev y en el siguiente reglón la otra. Si colocas: from “especifico” import ,si puedo colocar varias separadas por comas.

Lo que leí de las en el PEP #8 refiere a la manera de como debe estar estructurado de una manera especifica para poder seguir una guía del estilo de código como debe estar estructurado el código en los programas y códigos de Python con el fin de tener buenas prácticas.

Todo esta en la documentación...

En un inicio, ¿Es recomendable optar por una documentación más amable y pedagógica? ¿Por qué?