fieldenum: Hỗ trợ enum kiểu trường theo phong cách Rust trong Python
(github.com/ilotoki0804)- fieldenum là enum có mang giá trị (có thể khởi tạo instance).
- Hỗ trợ gọn gàng enum có trường của Rust.
- Được xây dựng để cân bằng giữa tính thuần túy của lập trình hàm và tính thực dụng trong Python.
- Mặc định hỗ trợ
Optionnhư một lựa chọn thay thế choNonevàBoundResultnhư một lựa chọn thay thế cho ngoại lệ. - Đã được kiểm thử đầy đủ.
- Tài liệu tiếng Anh hiện vẫn còn hạn chế, nhưng có kế hoạch bổ sung dần.
- Hoan nghênh mọi hình thức hỗ trợ như issue, PR, star, v.v.
14 bình luận
Tôi thấy kiểu union của
dataclasscó vẻ tốt hơn thì phải; ngoài việc câu lệnh khai báo ngắn hơn ra, tôi không thấy rõ ưu điểm lắm.fieldenumcó điểm gì vượt trội hơn một cách đặc biệt không?Ưu điểm lớn nữa là phần khai báo ngắn gọn, súc tích và chỉ chứa những gì cần thiết.
Ví dụ,
Nếu triển khai
fieldenumở trên bằngdataclassthì sẽ phải viết như sau.Mã dài hơn, khó nhìn hơn, khả năng mắc lỗi cũng cao hơn, và rõ ràng không mang lại cảm giác mã nguồn gọn gàng, đúng không?
Tất nhiên, ngay cả khi viết như vậy thì bạn vẫn không thể nhận được nhiều tính năng khác mà
fieldenumcung cấp (generic, repr,__fields__, ...).Vì vậy, sẽ tiện lợi hơn rất nhiều nếu có
fieldenumđã triển khai và gom sẵn toàn bộ những thứ này.Ngoài ra, bạn cũng nên tham khảo nội dung trong phần
ví dụ.dataclassvề cơ bản hỗ trợ triển khaireprmặc địnhdataclasses.fieldscung cấp thông tin thời gian chạy về định nghĩa các fieldtyping, còn syntactic sugar được hỗ trợ từ 3.12Messages, có thể triển khai bằng mô-đunDù vậy, việc không cần mã boilerplate để định nghĩa class, cùng với khả năng dùng
enumvà class dưới một giao diện thống nhất, có lẽ vẫn là những ưu điểm đáng giá. Cảm ơn vì phần giải thích chi tiết.https://stackoverflow.com/a/47784683
Đã có nhiều nỗ lực nhằm biểu diễn cấu trúc theo kiểu này, nhưng rốt cuộc có lẽ đây có thể xem là một giới hạn và cũng là nhược điểm của Python. Tôi lần đầu tiếp xúc với ADT (algebraic data type) trong giờ học ở trường qua OCaml, nên cũng có chút tiếc nuối khi lúc đi làm lại chỉ có thể mô phỏng theo kiểu này.
Có lẽ thư viện do ilotoki tạo ra là ví dụ gần với ADT nhất. Sẽ thật tuyệt nếu một ngày nào đó nó được đưa vào thư viện chuẩn và được sử dụng rộng rãi.
Nếu việc triển khai
Messageđược thực hiện bằng Union thì không thể tận dụng kế thừa phương thức. Ví dụ:Nếu thêm phương thức
.processnhư trên, thì có thể dùng phương thức.process()cho tất cả các variant.Ngoài ra,
reprmà tôi giải thích là "reprvới tư cách là variant của enum đó". Ví dụ, khi dùng fieldenum để bao bọc lời gọirepr, nó sẽ chạy như sau.Nếu không có
__repr__tùy chỉnh, thì sẽ không thể hiện được việc nó là variant con của enumMessage.Quitlà unit variant nên được dùng mà không cần gọi.Ngoài ra, với fieldless variant là loại variant cần dùng lời gọi, có thể kiểm tra bằng toán tử
isnhư một singleton.Dùng fieldenum sẽ giúp tự động xử lý nhiều chi tiết triển khai đa dạng rất dễ bị bỏ sót như thế này.
Hay là anh/chị thử cân nhắc trình bày tại PyCon Korea xem sao. Tôi thấy nội dung này cực kỳ thú vị, nên rất muốn được trực tiếp nghe câu chuyện và phần giải thích về quá trình anh/chị tạo ra nó!
Nếu có thể được trình bày tại PyCon thì thật sự sẽ là một vinh dự lớn. Dù không biết chỉ vì tôi muốn mà có thể làm được hay không(^^;), tôi sẽ thử suy nghĩ về việc này.
Và sẽ tốt hơn nếu ví dụ về
Optioncũng được giải thích trong README tiếng Anh.Optionsẽ dễ hiểu và tạo cảm giác quen thuộc để tiếp cận hơn. Tôi cũng nghĩ sẽ tốt hơn nếu giải thíchOptiontrước trong thứ tự trình bày của tài liệu.Tài liệu tiếng Anh vẫn đang được chuẩn bị nên hiện còn hơi sơ sài... Khi tài liệu tiếng Hàn đủ hoàn thiện, tôi định sẽ dịch sang tiếng Anh. Hoặc cũng rất hoan nghênh các PR liên quan!
Tôi cũng thấy việc giới thiệu
Optiontrước sẽ tốt hơn. Tôi sẽ sửa lại.Ồ. Thú vị thật!!
Trong ví dụ mã ở tài liệu tiếng Hàn mà bạn gửi có một chỗ cần sửa.
Cảm ơn bạn đã báo. Tôi đã sửa lại!
Đáng ra phải đăng bằng Show GN, nhưng tôi lại lỡ đăng ở mục thường mất rồi;;
Tôi đã sửa lại rồi.
Cảm ơn~