2014-09-25 13 views
11

Scenariusz: masz długą krotkę w wyniku zapytania SQL i chcesz rozpakować ją na poszczególne wartości. Jaki jest najlepszy sposób na to, dostosowując się do PEP8? Do tej pory mam te trzy opcje:Idiom dla rozpakowywania długich krotek

  1. pojedyncze zadanie, należy użyć backslash podzielić na wiele linii

    person_id, first_name, last_name, email, \ 
        birth_date, graduation_year, home_street, \ 
        home_city, home_zip, mail_street, mail_city, \ 
        mail_zip = row 
    
  2. pojedyncze zadanie, grupa po lewej stronie w nawiasach i przełamać linie bez backslashem

    (person_id, first_name, last_name, email, 
        birth_date, graduation_year, home_street, 
        home_city, home_zip, mail_street, mail_city, 
        mail_zip) = row 
    
  3. podzielone na wiele zadań, każde dopasowane do pojedynczej linii

    person_id, first_name, last_name, email = row[0:4] 
    birth_date, graduation_year, home_street = row[4:7] 
    home_city, home_zip, mail_street, mail_city = row[7:11] 
    mail_zip = row[11] 
    

Która z trzech opcji jest najlepsza? Czy jest coś lepszego?

+3

Oparte na opiniach. Nie podoba mi się rozwiązanie z odwróconym ukośnikiem na końcu linii, ponieważ kod zostanie przerwany, jeśli po nim pojawi się niewidoczny znak (np. Spacja). Dla mnie druga wersja jest drogą do zrobienia. – Matthias

+2

Czy brałeś pod uwagę jeden ['namedtuple'] (https://docs.python.org/2/library/collections.html#collections.namedtuple) zamiast oddzielnych nazw? – jonrsharpe

+3

@ Matthias On pyta "podczas dostosowywania się do PEP-8", a PEP-8 jest dość jednoznaczny o tym, którego użyć. – chepner

Odpowiedz

13

Anwering your question "Która z trzech opcji jest najlepsza?"

pep8 stanowi:

Korzystnym sposobem pakowania długie linie, jest za pomocą Pythona wynikało kontynuacji linii wewnątrz okrągłe, kwadratowe i stężeń. Długie linie mogą być przerywane na wiele linii poprzez zawijanie wyrażeń w nawiasach. Powinny być one używane zamiast używania odwrotnego ukośnika do kontynuacji linii.

To oznacza, że ​​drugi jest preferowany nad pierwszym. Trzeci jest dobrze dopasowany do pep8, choć osobiście nie polecałby tego.

+1

+1 Trzeci jest znacznie mniej wydajny, wymagający wielu kodów bajtowych, aby wykonać to samo zadanie. – chepner

5

Aby odpowiedzieć „czy jest coś lepszego”, chciałbym zaproponować, że namedtuple pozwala na dostęp do poszczególnych elementów danych z minimalnym zamieszanie:

>>> from collections import namedtuple 
>>> Person = namedtuple("Person", ['person_id', 'first_name', 'last_name', 
            'email', 'birth_date', 'graduation_year', 
            'home_street', 'home_city', 'home_zip', 
            'mail_street', 'mail_city', 'mail_zip']) 
>>> row = range(12) # dummy data 
>>> p = Person(*row) # unpack tuple into namedtuple 
>>> p 
Person(person_id=0, first_name=1, last_name=2, email=3, birth_date=4, graduation_year=5, home_street=6, home_city=7, home_zip=8, mail_street=9, mail_city=10, mail_zip=11) 
>>> p.birth_date 
4 

Oznacza to, że dostęp do atrybutów, zamiast odrębnych nazw , ale jest lżejszy niż tworzenie klasy, zachowuje wszystkie dane z zapytania razem i ujawnia wartości poprzez sensowne nazwy.

+0

To wygląda dobrze, o ile musisz zrobić to wiele razy dla tej samej sekwencji atrybutów. Jednakże, jeśli wiesz, że nie rozpakujesz takiego rzędu w więcej niż jednym miejscu, prawdopodobnie jest to zbyt duża waga (zamiast pojedynczego lub kilku przydziałów, musisz zaimportować kolekcję, zdefiniować nazwaną krotkę itp. Tylko dla pojedynczego rozpakowywanie). – koniiiik

+0

@koniiiik na dokumentach, 'namedtuple's *" nie wymaga więcej pamięci niż zwykłe krotki "*. Definiowanie kontenera ma taką samą długość jak obecnie rozpakowywanie, więc dodajesz tylko dwa wiersze ("importuj" i rozpakuj). Jeśli masz pewność, że użyjesz go tylko raz, możesz mieć rację. – jonrsharpe

+1

Cóż, przynajmniej składa się z nie całkiem banalnych kroków, które mogą sprawić, że będzie mniej oczywiste, co się dzieje.Ale znowu, zależy od dokładnej sytuacji. – koniiiik

Powiązane problemy