Có bao giờ lịch sự để đặt mã trong một tệp cấu hình python không?

Question

Một trong những tính năng yêu thích của tôi về python là bạn có thể viết các tệp cấu hình trong python rất đơn giản để đọc và hiểu. Nếu bạn đặt một vài ranh giới về bản thân, bạn có thể khá tự tin rằng những người không phải pythonistas sẽ biết chính xác những gì bạn muốn nói và sẽ hoàn toàn có khả năng cấu hình lại chương trình của bạn.

Câu hỏi của tôi là, chính xác những ranh giới đó là gì? Riêng của tôi heuristic cá nhân là

1. Tránh kiểm soát dòng chảy. Không có hàm, vòng lặp hoặc điều kiện nào. Những người sẽ không được trong một tập tin cấu hình văn bản và mọi người không mong đợi để có hiểu chúng. Nói chung, nó có thể không quan trọng thứ tự mà các câu lệnh của bạn thực thi.
2. Dính vào các bài tập theo nghĩa đen. Các phương thức và hàm được gọi trên các đối tượng khó suy nghĩ hơn. Bất cứ điều gì tiềm ẩn sẽ là một mớ hỗn độn. Nếu có điều phức tạp nào đó xảy ra với các thông số của bạn, hãy thay đổi cách chúng được diễn giải.
3. Từ khóa ngôn ngữ và xử lý lỗi là đúng.

Tôi đoán tôi hỏi điều này vì tôi tình cờ thấy một tình huống với tệp cấu hình Django của tôi ở đó có vẻ hữu ích khi phá vỡ các quy tắc này. Tôi tình cờ thích nó, nhưng tôi cảm thấy một chút tội lỗi. Về cơ bản, dự án của tôi được triển khai thông qua kiểm tra svn với một vài máy chủ khác nhau mà sẽ không được cấu hình giống nhau (một số sẽ chia sẻ cơ sở dữ liệu, một số sẽ không, ví dụ). Vì vậy, tôi ném một cái móc vào cuối:

try: 
    from settings_overrides import * 
    LOCALIZED = True 
except ImportError: 
    LOCALIZED = False 

nơi settings_overrides nằm trên đường dẫn python nhưng bên ngoài bản sao làm việc. Bạn nghĩ gì, hoặc về ví dụ này, hoặc về ranh giới cấu hình python nói chung?

Answer 1

Có trang wiki Django, địa chỉ chính xác thứ bạn đang yêu cầu. http://code.djangoproject.com/wiki/SplitSettings

Không phát minh lại bánh xe. Sử dụng các tệp configparser và INI. Các tệp Python dễ bị phá vỡ bởi ai đó, những người không biết Python.

Answer 2

Phương pháp chẩn đoán của bạn là tốt. Quy tắc được thực hiện để ranh giới được thiết lập và chỉ bị phá vỡ khi nó rõ ràng là một giải pháp tốt hơn rất nhiều so với thay thế.

Tuy nhiên, tôi không thể không tự hỏi rằng mã kiểm tra trang web phải nằm trong trình phân tích cú pháp và một mục cấu hình bổ sung được thêm vào để chọn tùy chọn nào sẽ được thực hiện.

Tôi không nghĩ rằng trong trường hợp này thay thế là xấu như vậy mà phá vỡ các quy tắc làm cho tinh thần ...

-Adam

Answer 3

Tôi nghĩ đó là một nỗi đau vs luận niềm vui.

Không phải là sai để đặt mã trong tệp cấu hình Python vì đó là tất cả Python hợp lệ, nhưng điều đó có nghĩa là bạn có thể gây nhầm lẫn cho người dùng đã định cấu hình lại ứng dụng. Nếu bạn lo lắng về điều đó, hãy kết nối nó với các bình luận giải thích về những gì nó làm và người dùng không nên chỉnh sửa nó, thay vì chỉnh sửa tệp settings_overrides.py.

Như ví dụ của bạn, hãy xem số cần thiết để nhà phát triển thử nghiệm sau đó triển khai ứng dụng của họ. Niềm vui hơn cả đau đớn.Nhưng bạn thực sự nên làm điều này thay vì:

LOCALIZED = False 

try: 
    from settings_overrides import * 
except ImportError: 
    pass 

Và trong tập tin settings_overrides.py của bạn:

LOCALIZED = True 

... Nếu không có gì nhưng để làm cho nó rõ ràng những gì tập tin mà không .. Những gì bạn đang làm ở đó chia tách ghi đè thành hai nơi.

Answer 4

Thông thường, hãy xem các câu trả lời khác trên trang; tất cả phụ thuộc vào. Cụ thể cho Django, tuy nhiên, tôi thấy không có gì sai lầm cơ bản với viết code trong file settings.py ... sau khi tất cả, các tập tin cài đặt là mã :-)

Các Django docs on settings themselves nói:

Một thiết lập tập tin chỉ là một mô-đun Python với các biến cấp mô-đun.

Và đưa ra ví dụ:

assign settings dynamically using normal Python syntax. For example: 
MY_SETTING = [str(i) for i in range(30)] 

Answer 5

Cài đặt như mã cũng là một nguy cơ bảo mật. Bạn nhập "cấu hình" của bạn, nhưng trong thực tế bạn đang thực thi bất kỳ mã nào có trong tệp đó. Đặt cấu hình trong các tệp mà bạn phân tích cú pháp đầu tiên và bạn có thể từ chối các giá trị vô nghĩa hoặc độc hại, ngay cả khi nó hoạt động tốt hơn cho bạn. Tôi blogged về điều này trong tháng 12 năm 2008.