python - pep257 - Formato de código SQLAlchemy

pep8 wikipedia

Question

Estamos tratando de seguir las pautas de PEP8 para formatear nuestro código Python y mantenernos por debajo de 80 caracteres por línea.

Nuestras líneas SQLAlchemy son particularmente problemáticas, ya que tienen muchos métodos encadenados y toneladas de parámetros complejos, lógica y funciones anidadas.

¿Existen prácticas recomendadas particulares para formatear Python SQLAlchemy con las restricciones de PEP8?

La respuesta más cercana que he encontrado está here , pero el código con el que estoy tratando es mucho más complicado.

Answer 1

Sí, estos serán desagradables sin importar lo que hagas, por lo que en la medida en que puedas dividir estas construcciones en líneas más cortas, definitivamente, hazlo.

Cuando no pueda, probablemente pueda deshacerse de todas esas barras invertidas colocando el RHS completo entre paréntesis. Python luego analizará las construcciones multilínea correctamente sin las barras invertidas, pero también es difícil decir si eso es mejor o no. En casos como estos, creo que solo tienes que usar tu mejor juicio, aguantarte la nariz y sumergirte.

Answer 2

Soy un usuario frecuente de las barras invertidas de manera similar a lo que zzzeek indicó en su respuesta. PEP8 es solo una guía, ¡no pierdas el sueño cuando lo infrinjas!

Sin embargo, también uso con frecuencia el tipo de formato a continuación, donde robé el primer ejemplo de zzzeek, ​​lo modifiqué ligeramente y lo reformateé:

q = Session.query(
    Subkeyword.subkeyword_id, 
    Subkeyword.subkeyword_word,
)
q = q.filter_by(subkeyword_company_id=self.e_company_id)  # first filter
q = q.filter_by(subkeyword_word=subkeyword_word)  # 2nd filter
q = q.filter_by(subkeyword_active=True)

if filter_by_foo:
    q = q.filter(Subkeyword.foo == True)

# Run the query (I usually wrap in a try block)...
subkeyword = q.one()

La reasignación repetida a q parece un poco desagradable al principio, pero ya lo superé. El impacto en el rendimiento es efectivamente nulo. Una gran ventaja de esta manera es que puede combinar tanto los comentarios finales como las líneas de comentarios para documentar sus consultas (como lo he hecho con las adiciones inútiles anteriores). Encadenar líneas con barras invertidas te limita aquí.

Esta forma de formato es particularmente clara cuando se formulan consultas masivas con toneladas de modificaciones activadas por lógica, selecciones escalares incrustadas, etc.

Como otro ejemplo, tengo una consulta de CTE bastante grande (> 150 líneas) que estoy generando en SQLAlchemy que tiene mucha lógica mixta, aliasing y etiquetado (que es esencial para la legibilidad de la consulta generada) que mezcla ambos métodos. Una versión seriamente reducida (y destrozada) comienza algo como a continuación:

cte_init = session./
    query(
        child1.foo.label("child1_foo"),
        sa.literal(1).label("indent"),  # can comment on non-slashed lines
        child2.bar.label("child2bar"),
        #comments between non-slashed lines ok, too 
        sa.func.MAX(toplevel.baz).label("max_baz"),
    )./
    select_from(top_level)./
    join(child1,
         child1.id == toplevel.fk_child1_id)./
    join(child2.
         child2.id == toplevel.fk_child2.id)./
    filter(top_level.name == "bogus")./
    cte(name = "cte", recursive = True)

if(use_filter_x):
    cte_init = cte_init.filter_by(x = "whatever")

# etc (no, the above doesn''t make any sense)...

En general, si se asegura de llevar sus líneas con las nuevas operaciones (como lo hacen muchos esquemas comunes de formateo de SQL), sigue siendo bastante legible. No tengas miedo de las nuevas líneas entre paréntesis, tampoco.

Answer 3

Vine aquí con la esperanza de una mejor solución, pero creo que prefiero el estilo de ajuste de paréntesis:

subkeyword = (
    Session.query(
        Subkeyword.subkeyword_id, 
        Subkeyword.subkeyword_word
    )
    .filter_by(subkeyword_company_id=self.e_company_id)
    .filter_by(subkeyword_word=subkeyword_word)
    .filter_by(subkeyword_active=True)
    .one()
)

Esto es agradable y claro, y evita la barra invertida temida.

Answer 4

pep-8 desalienta las barras invertidas, pero para el código SQLAlchemy no puedo evitar pensar que son las más legibles, ya que puedes mantener cada función generativa al comienzo de su propia línea. Si hay muchos argumentos dentro de paréntesis, también los separaré en líneas individuales.

subkeyword = Session.query(
                  Subkeyword.subkeyword_id, 
                  Subkeyword.subkeyword_word
             )./
               filter_by(subkeyword_company_id=self.e_company_id)./
               filter_by(subkeyword_word=subkeyword_word)./
               filter_by(subkeyword_active=True)./
               one()

por supuesto, no importa lo complicado que sea el código, el patrón de sangrado se puede llevar a cabo para cualquier cantidad de código, sin embargo, en Python queremos evitar el anidamiento excesivo. Por lo general, con Query, el anidamiento ocurriría porque estás componiendo muchas subconsultas juntas. Así que definitivamente construir las subconsultas antes de tiempo:

subq = Session.query(
                Bat.id, 
                func.foo(Bat.x, Bat.y).label(''foo'')
               )./
                filter(Bat.id==Bar.name)./
                correlate(Bar)./
                subquery()

subq2 = Session.query(Foo.id, Foo.bar)./
                filter_by(flag>5)./
                subquery()

result = Session.query(
                  subq.c.id,
                  subq.c.foo,
                  subq2.c.bar
                )./
                join(subq2, 
                     and_(
                      subq.c.id > subq2.c.foo, 
                      subq.bar == subq2.id
                     )
                )./
                order_by(subq.c.id, subq2.c.bar)

Daría la bienvenida a otras opiniones sobre la barra invertida.