Dlaczego używanie słowa „eval” jest złą praktyką?

Używam następującej klasy, aby łatwo przechowywać dane moich piosenek.

class Song:
    """The class to store the details of each song"""
    attsToStore=('Name', 'Artist', 'Album', 'Genre', 'Location')
    def __init__(self):
        for att in self.attsToStore:
            exec 'self.%s=None'%(att.lower()) in locals()
    def setDetail(self, key, val):
        if key in self.attsToStore:
            exec 'self.%s=val'%(key.lower()) in locals()

Uważam, że jest to o wiele bardziej rozszerzalne niż pisanie if/elsebloku. Jednak evalwydaje się być uważany za złą praktykę i niebezpieczny w użyciu. Jeśli tak, czy ktoś może mi wyjaśnić dlaczego i pokazać lepszy sposób zdefiniowania powyższej klasy?

Tak, używanie eval to zła praktyka. Żeby wymienić tylko kilka powodów:

1. Prawie zawsze jest na to lepszy sposób
2. Bardzo niebezpieczny i niepewny
3. Utrudnia debugowanie
4. Powolny

W twoim przypadku możesz zamiast tego użyć setattr :

class Song:
    """The class to store the details of each song"""
    attsToStore=('Name', 'Artist', 'Album', 'Genre', 'Location')
    def __init__(self):
        for att in self.attsToStore:
            setattr(self, att.lower(), None)
    def setDetail(self, key, val):
        if key in self.attsToStore:
            setattr(self, key.lower(), val)

EDYTOWAĆ:

W niektórych przypadkach musisz użyć funkcji eval lub exec. Ale są rzadkie. Używanie eval w twoim przypadku jest z pewnością złą praktyką. Podkreślam złe praktyki, ponieważ eval i exec są często używane w niewłaściwym miejscu.

EDYCJA 2:

Wygląda na to, że niektórzy nie zgadzają się, że eval jest „bardzo niebezpieczny i niepewny” w przypadku OP. Może to być prawdą w tym konkretnym przypadku, ale nie ogólnie. Pytanie było ogólne, a powody, które wymieniłem, są prawdziwe również dla przypadku ogólnego.

EDYCJA 3: Zmieniono kolejność punktów 1 i 4

Używanie evaljest słabe i nie jest wyraźnie złą praktyką.

1. Narusza „Podstawową zasadę oprogramowania”. Twoje źródło nie jest sumą tego, co jest wykonywalne. Oprócz twojego źródła istnieją argumenty eval, które należy jasno zrozumieć. Z tego powodu jest to narzędzie ostatniej szansy.

2. Zwykle jest to oznaka bezmyślnego projektu. Rzadko istnieje dobry powód dla dynamicznego kodu źródłowego, budowanego w locie. Prawie wszystko można zrobić za pomocą delegacji i innych technik projektowania obiektowego.

3. Prowadzi to do stosunkowo powolnej kompilacji małych fragmentów kodu w locie. Narzut, którego można uniknąć, stosując lepsze wzorce projektowe.

Jak przypis, w rękach obłąkanych socjopatów może się to nie udać. Jednak w konfrontacji z obłąkanymi socjopatycznymi użytkownikami lub administratorami najlepiej nie dawać im interpretowanego języka Python. W rękach naprawdę złego Python może być ciężarem;evalw ogóle nie zwiększa ryzyka.

W tym przypadku tak. Zamiast

exec 'self.Foo=val'

powinieneś użyć wbudowanej funkcji setattr:

setattr(self, 'Foo', val)

Tak to jest:

Hack używając Pythona:

>>> eval(input())
"__import__('os').listdir('.')"
...........
...........   #dir listing
...........

Poniższy kod zawiera listę wszystkich zadań uruchomionych na komputerze z systemem Windows.

>>> eval(input())
"__import__('subprocess').Popen(['tasklist'],stdout=__import__('subprocess').PIPE).communicate()[0]"

W systemie Linux:

>>> eval(input())
"__import__('subprocess').Popen(['ps', 'aux'],stdout=__import__('subprocess').PIPE).communicate()[0]"

Warto zauważyć, że w przypadku konkretnego problemu istnieje kilka alternatyw do użycia eval:

Najprostszym, jak wspomniano, jest użycie setattr:

def __init__(self):
    for name in attsToStore:
        setattr(self, name, None)

Mniej oczywistym podejściem jest bezpośrednia aktualizacja obiektu __dict__obiektu. Jeśli wszystko, co chcesz zrobić, to zainicjować atrybuty None, jest to mniej proste niż powyższe. Ale rozważ to:

def __init__(self, **kwargs):
    for name in self.attsToStore:
       self.__dict__[name] = kwargs.get(name, None)

Pozwala to na przekazanie argumentów słów kluczowych do konstruktora, np .:

s = Song(name='History', artist='The Verve')

Pozwala także na locals()bardziej jednoznaczne użycie , np .:

s = Song(**locals())

... a jeśli naprawdę chcesz przypisać Nonedo atrybutów, których nazwy znajdują się w locals():

s = Song(**dict([(k, None) for k in locals().keys()]))

Innym podejściem do dostarczenia obiektowi wartości domyślnych dla listy atrybutów jest zdefiniowanie metody klasy __getattr__:

def __getattr__(self, name):
    if name in self.attsToStore:
        return None
    raise NameError, name

Ta metoda jest wywoływana, gdy nazwany atrybut nie zostanie znaleziony w normalny sposób. To podejście jest nieco mniej proste niż po prostu ustawienie atrybutów w konstruktorze lub zaktualizowanie pliku__dict__ , ale ma tę zaletę, że nie tworzy atrybutu, chyba że istnieje, co może znacznie zmniejszyć użycie pamięci klasy.

W tym wszystkim chodzi o to, że istnieje wiele powodów, których należy unikać eval- problem bezpieczeństwa związany z wykonywaniem kodu, którego nie kontrolujesz, praktyczny problem kodu, którego nie możesz debugować itp. Ale jeszcze ważniejszy powód polega na tym, że generalnie nie musisz go używać. Python udostępnia programiście tyle swoich wewnętrznych mechanizmów, że rzadko trzeba pisać kod, który pisze kod.

Inni użytkownicy wskazywali, jak można zmienić kod, aby nie polegać na eval; Zaproponuję uzasadniony przypadek użycia eval, który można znaleźć nawet w CPythonie: testing .

Oto jeden przykład, który znalazłem, test_unary.pygdzie test sprawdzający, czy (+|-|~)b'a'podnosi a TypeError:

def test_bad_types(self):
    for op in '+', '-', '~':
        self.assertRaises(TypeError, eval, op + "b'a'")
        self.assertRaises(TypeError, eval, op + "'a'")

Użycie nie jest tutaj złą praktyką; definiujesz dane wejściowe i po prostu obserwujesz zachowanie. evaljest przydatny do testowania.

Spójrz na tego wyszukiwania dla evalprzeprowadzana jest na git repozytorium CPython; testowanie z eval jest często używane.

Gdy eval()jest używany do przetwarzania danych wejściowych wprowadzonych przez użytkownika, umożliwiasz użytkownikowi Drop-to-REPL, podając coś takiego:

"__import__('code').InteractiveConsole(locals=globals()).interact()"

Może ci się to udać, ale zwykle nie chcesz wektorów do wykonywania dowolnego kodu w swoich aplikacjach.

Oprócz odpowiedzi @Nadia Alramli, ponieważ jestem nowy w Pythonie i bardzo chciałem sprawdzić, jak użycie evalwpłynie na czasy , wypróbowałem mały program i poniżej były spostrzeżenia:

#Difference while using print() with eval() and w/o eval() to print an int = 0.528969s per 100000 evals()

from datetime import datetime
def strOfNos():
    s = []
    for x in range(100000):
        s.append(str(x))
    return s

strOfNos()
print(datetime.now())
for x in strOfNos():
    print(x) #print(eval(x))
print(datetime.now())

#when using eval(int)
#2018-10-29 12:36:08.206022
#2018-10-29 12:36:10.407911
#diff = 2.201889 s

#when using int only
#2018-10-29 12:37:50.022753
#2018-10-29 12:37:51.090045
#diff = 1.67292