2014-12-13 10 views
6

Na przykład chcę użyć funkcji numpy '. Mam już załadowaną bibliotekę pand:Czy używanie pakietu importowanego przez inny pakiet jest niepythoniczne, czy też powinienem go zaimportować bezpośrednio?

import pandas as pd 

pd.np.isnan(1) #=> False 

To działa, ale czy jest jakaś wada? Czy mogę napisać:

import pandas as pd 
import numpy as np 

np.isnan(1) #=> False 

Co to jest dobra praktyka?

+1

myślę, że to faktycznie ma odpowiedź opartą na faktach, pokryte PEP [8] (https://www.python.org/dev/peps/pep-0008/#public-and-internal- interfejsy) i powinny zostać ponownie otwarte. – abarnert

+2

W skrócie: 'np' nie jest udokumentowane w' help (pd) 'lub w sieciowej pomocy Pandy i" Wszystkie nieudokumentowane interfejsy powinny być założone jako wewnętrzne. " Fakt, że Pandas nie ma '__all__', który wyklucza' np' lub 'import numpy jako _np' jest mniejszy niż idealny (choć nie w takim stopniu, jak bym to nazwał błędem), ale nadal nie oznacza, że ​​przypadkowo wyeksponowane nazwy, które nie są udokumentowane, są częścią publicznego interfejsu. – abarnert

+2

Poza tym, co zostało już powiedziane, nie ma wpływu na wydajność ponownego importowania 'numpy', ponieważ Python buforuje import. –

Odpowiedz

10

Należy użyć drugiego podejścia do co najmniej czterech powodów:

  1. Jak @abarnert powiedział w komentarzach, wynika z oficjalnych wytycznych dla kodu Pythona, jak stwierdzono w PEP 0008 pod Public and internal interfaces. W szczególności PEP mówi:

    Należy uznać, że wszystkie nieudokumentowane interfejsy mają charakter wewnętrzny.

    oraz:

    Importowane nazwy powinny być zawsze traktowane szczegółów wdrażania. Inne moduły nie muszą polegać na pośredni dostęp do takich nazw importowanych chyba że są one wyraźnie udokumentowanym część zawierająca modułu API, takich jak os.path lub moduł pakietu za __init__ że eksponuje funkcjonalność z submodules.

    Ponieważ NumPy jest nieudokumentowana aspekt biblioteki Pandy (to nie jest wymienione w obu help(pd) ani na oficjalnej stronie), to nie powinno być traktowane jako oficjalna część Pandy.

  2. "Explicit is better than implicit" a drugie podejście wyraźnie informuje, że korzystamy z biblioteki NumPy bezpośrednio w kodzie. Pierwsze podejście jednak trochę "wsuwa" przez bibliotekę Pand.

  3. Narzędzia do analizy kodu nie będą w stanie zobaczyć, że Twój kod używa bezpośrednio NumPy. Mogłoby to generować fałszywe dane dotyczące twojego kodu (takie, jakie to ma zależności).

  4. Fakt, że Panda zawiera NumPy, to nic innego jak szczegół implementacji. To znaczy, gdyby twórcy Pand kiedykolwiek zmienili swój wewnętrzny kod, aby w jakikolwiek sposób zmienić ten szczegół, cały twój kod Numpy'ego może nagle się zepsuć, gdy naprawdę nie powinien. Numpy i Pandy to dwie odrębne rzeczy i powinny być traktowane jako takie.

+0

Nie jestem pewien o # 3; Jestem pewien, że niektóre metody Pandy są udokumentowane, aby wyraźnie zwrócić i/lub wziąć tablice NumPy, a fakt, że Panda jest zbudowana na NumPy, jest czymś, co myślę, że wszyscy tak myślą. (Jednakże nie oznacza to, że Panda musi eksportować 'numpy' jako' np', oczywiście, co powraca do pierwszych dwóch odpowiedzi.) – abarnert

+0

Właśnie wprowadziłem to z mojego komentarza do mojej odpowiedzi. Nie używam Pand za dużo, więc znam tylko podstawy. Zmienię sformułowanie, by było mniej surowe. – iCodez

Powiązane problemy