Tại sao sử dụng 'eval' là một thực hành xấu?

Tôi đang sử dụng lớp sau để dễ dàng lưu trữ dữ liệu các bài hát của mình.

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()

Tôi cảm thấy rằng điều này chỉ mở rộng hơn nhiều so với việc viết ra một if/elsekhối. Tuy nhiên, evaldường như được coi là một thực hành xấu và không an toàn để sử dụng. Nếu vậy, bất cứ ai có thể giải thích cho tôi tại sao và chỉ cho tôi một cách tốt hơn để xác định lớp trên?

Vâng, sử dụng eval là một thực hành xấu. Chỉ cần nêu một vài lý do:

1. Hầu như luôn luôn có một cách tốt hơn để làm điều đó
2. Rất nguy hiểm và không an toàn
3. Làm cho việc sửa lỗi trở nên khó khăn
4. Chậm

Trong trường hợp của bạn, bạn có thể sử dụng setattr thay thế:

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)

BIÊN TẬP:

Có một số trường hợp bạn phải sử dụng eval hoặc exec. Nhưng chúng rất hiếm. Sử dụng eval trong trường hợp của bạn là một thực tế xấu chắc chắn. Tôi nhấn mạnh vào thực tiễn xấu vì eval và exec thường được sử dụng sai chỗ.

EDIT 2:

Có vẻ như một số người không đồng ý rằng eval là 'rất nguy hiểm và không an toàn' trong trường hợp OP. Điều đó có thể đúng với trường hợp cụ thể này nhưng không nói chung. Câu hỏi rất chung chung và những lý do tôi liệt kê cũng đúng cho trường hợp chung.

EDIT 3: Sắp xếp lại điểm 1 và 4

Sử dụng evallà yếu, không phải là một thực hành xấu rõ ràng .

1. Nó vi phạm "Nguyên tắc cơ bản của phần mềm". Nguồn của bạn không phải là tổng số của những gì có thể thực hiện được. Ngoài nguồn của bạn, còn có các đối số eval, phải được hiểu rõ ràng. Vì lý do này, nó là công cụ cuối cùng.

2. Nó thường là một dấu hiệu của thiết kế thiếu suy nghĩ. Hiếm khi có một lý do chính đáng cho mã nguồn động, được xây dựng nhanh chóng. Hầu như bất cứ điều gì có thể được thực hiện với ủy quyền và các kỹ thuật thiết kế OO khác.

3. Nó dẫn đến việc biên dịch tương đối chậm trên các đoạn mã nhỏ. Một chi phí có thể tránh được bằng cách sử dụng các mẫu thiết kế tốt hơn.

Như một chú thích, trong tay của những kẻ xã hội loạn trí, nó có thể không hoạt động tốt. Tuy nhiên, khi phải đối mặt với người dùng hoặc quản trị viên xã hội loạn trí, tốt nhất là không cho họ giải thích Python ngay từ đầu. Trong tay của kẻ ác thực sự, Python có thể phải chịu trách nhiệm; evalkhông làm tăng rủi ro

Trong trường hợp này, có. Thay vì

exec 'self.Foo=val'

bạn nên sử dụng hàm dựng sẵnsetattr :

setattr(self, 'Foo', val)

Vâng, đúng vậy:

Hack bằng Python:

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

Đoạn mã dưới đây sẽ liệt kê tất cả các tác vụ đang chạy trên máy Windows.

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

Trong Linux:

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

Điều đáng chú ý là đối với vấn đề cụ thể đang được đề cập, có một số lựa chọn thay thế cho việc sử dụng eval :

Đơn giản nhất, như đã lưu ý, là sử dụng setattr:

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

Một cách tiếp cận ít rõ ràng hơn là cập nhật __dict__trực tiếp đối tượng của đối tượng. Nếu tất cả những gì bạn muốn làm là khởi tạo các thuộc tính None, thì điều này ít đơn giản hơn so với ở trên. Nhưng hãy xem xét điều này:

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

Điều này cho phép bạn chuyển các đối số từ khóa cho hàm tạo, ví dụ:

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

Nó cũng cho phép bạn sử dụng locals()rõ ràng hơn, ví dụ:

s = Song(**locals())

... và, nếu bạn thực sự muốn gán Nonecho các thuộc tính có tên được tìm thấy trong locals():

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

Một cách tiếp cận khác để cung cấp một đối tượng với các giá trị mặc định cho danh sách các thuộc tính là xác định __getattr__phương thức của lớp :

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

Phương thức này được gọi khi thuộc tính được đặt tên không được tìm thấy theo cách thông thường. Cách tiếp cận này hơi đơn giản hơn là chỉ đơn giản là đặt các thuộc tính trong hàm tạo hoặc cập nhật__dict__ , nhưng nó có ưu điểm là không thực sự tạo thuộc tính trừ khi nó tồn tại, điều này có thể làm giảm đáng kể việc sử dụng bộ nhớ của lớp.

Vấn đề của tất cả những điều này: nói chung, có rất nhiều lý do để tránh eval- vấn đề bảo mật khi thực thi mã mà bạn không kiểm soát, vấn đề thực tế về mã bạn không thể gỡ lỗi, v.v. Nhưng một lý do thậm chí còn quan trọng hơn nói chung là bạn không cần sử dụng nó. Python tiết lộ rất nhiều cơ chế bên trong của nó cho lập trình viên mà bạn hiếm khi thực sự cần phải viết mã viết mã.

Những người dùng khác chỉ ra cách mã của bạn có thể được thay đổi để không phụ thuộc vào eval; Tôi sẽ cung cấp một trường hợp sử dụng hợp pháp để sử dụng eval, một trường hợp được tìm thấy ngay cả trong CPython: thử nghiệm .

Đây là một ví dụ tôi tìm thấy trong test_unary.pyđó một bài kiểm tra về việc có (+|-|~)b'a'làm tăng TypeError:

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

Việc sử dụng rõ ràng là thực hành không tồi ở đây; bạn xác định đầu vào và chỉ quan sát hành vi. evallà tiện dụng để thử nghiệm.

Hãy nhìn vào tìm kiếm này cho eval, thực hiện trên kho git CPython; thử nghiệm với eval được sử dụng rất nhiều.

Khi eval()được sử dụng để xử lý dữ liệu đầu vào do người dùng cung cấp, bạn cho phép người dùng Drop-to-REPL cung cấp một cái gì đó như thế này:

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

Bạn có thể thoát khỏi nó, nhưng thông thường bạn không muốn các vectơ để thực thi mã tùy ý trong các ứng dụng của mình.

Ngoài câu trả lời @Nadia Alramli, vì tôi chưa quen với Python và rất muốn kiểm tra việc sử dụng evalsẽ ảnh hưởng đến thời gian như thế nào , tôi đã thử một chương trình nhỏ và dưới đây là các quan sát:

#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