2010-09-05 9 views
31

Estoy empezando a usar PyQt en algunos proyectos y me encuentro con un dilema estilístico. Las funciones de PyQt usan camel case, pero PEP8, que prefiero seguir, dice que use guiones bajos y todas minúsculas para nombres de funciones. Entonces, por un lado, puedo seguir PEP8, lo que significa que mi código tendrá funciones mixtas llamadas a camel case y funciones de subrayado, e incluso mis clases tendrán nombres de funciones mixtas, ya que necesitaré sobrecargar funciones como mousePressEvent . O bien, puedo romper PEP8 y adoptar camel case para todos mis nombres de funciones en nombre de la consistencia.PEP8 y PyQt, cómo conciliar

Me doy cuenta de que esto es subjetivo y es realmente lo que personalmente prefiero, pero me gusta escuchar a otros sobre lo que hacen y por qué eligieron hacerlo de esa manera.

+0

Estoy comenzando con PyQt. ¿Son las funciones el único problema, o las variables PyQt también son comúnmente accedidas? Estoy considerando usar camelCase para funciones en mi código de IU de PyQt, pero sigo las convenciones de PEP8 para nombres de variables. Me preocupa que posiblemente crear una mezcla desordenada más tarde, sin embargo. –

+0

De todos modos, no estoy totalmente de acuerdo en que esto sea subjetivo. Aprecio PyQt, pero creo que han hecho un mal servicio al no seguir a PEP8. (Por otra parte, incluso el nombre de la biblioteca no es muy pitónico._QtPy_ hubiera sido mucho mejor, dado que todos los desarrolladores de habla inglesa que he conocido, en dos continentes, lo pronunciarían como 'cutie-pie'. ;-)) –

Respuesta

28

En sus zapatos, no pelearía contra su marco, al igual que, como principio general, no lucho contra el Ayuntamiento ;-). Comparto tu preferencia por los nombres de las funciones en minúsculas con guiones bajos, como especifica PEP 8, pero cuando estoy programando en un marco que fuerza un estilo de mayúsculas diferente, me resigno a adoptar ese estilo también, ya que no puedo convencer el marco para adoptar el estilo "mejor" y las inconsistencias de estilo (mezclas fortuitas de diferentes estilos) son realmente peores.

Por supuesto, algunos mixage es inevitable si está usando más de un marco ... por ejemplo, PyQt con su CamelCase, y funciones estándar de la biblioteca de Python con sus minúsculas y subrayado -!). Pero dado que los frameworks como Qt suelen ampliarse mediante subclases, mientras que la biblioteca estándar de Python tiene menos aspectos de dicho diseño, en la mayoría de los casos donde el estilo de capitalización es forzado (porque debe sobrescribir un método, por lo que no puede elija una mayúscula diferente), se forzará a camelcase (por Qt), solo raramente a minúsculas (por la biblioteca estándar de Python). Entonces, creo que adoptar el estilo Qt en este caso sigue siendo el mal menor.

6

Usa lo que mejor se adapte.

Si está subclasificando clases Qt, o tiene una función fuertemente integrada con ellos UseCamelCase.

De lo contrario, use_underscores.

+10

Esto muestra explícitamente a los lectores del código lo que está conectado a Qt, y lo que no. – EOL

+0

Y en una buena aplicación, una cantidad mínima de código realmente usará el kit de herramientas GUI de todos modos. – phkahler

0

Quizás el uso razonable de módulos para separar los estilos en diferentes módulos pueda ayudar. Al menos intente modularizar el código básico de estilo PEP8 al propio módulo de funciones auxiliares.

1

Puede usar guiones bajos si lo subclase. Y puede nombrar sus métodos con guiones bajos y PyQt4 podrá usarlos como si los hubiera nombrado con camelCase.

class SomeClass(object): 
    def __getattr__(self, attr): 
     if '_' in attr: 
      new = [c for c in attr] 
      while True: 
       try: 
        new_char = new[new.index('_') + 1].upper() 
        new[new.index('_'):new.index('_') + 2] = new_char 
       except (IndexError, ValueError): 
        break 
     else: 
      for c in attr: 
       if c.isupper(): 
        new = [] 
        for i, c in enumerate(attr): 
         if i != 0 and c.isupper(): 
          new.append('_') 
         new.append(c.lower()) 
        break 
     try: 
      return super(type(self), self).__getattribute__(''.join(new)) 
     except Exception: 
      return super(type(self), self).__getattribute__(attr) 
+6

Eso es una gran cantidad de trucos para, a lo sumo, un efecto cosmético. –

11

El documento PEP8 dice qué hacer en este caso (el énfasis es mío):

nuevos módulos y paquetes (incluidos los marcos de terceros) debe ser escrito a estas normas, pero donde una biblioteca existente tiene un estilo diferente, se prefiere la consistencia interna.