Các nhà phát triển Python tranh luận về cú pháp viết tắt cho keyword arguments theo thực tiễn tốt nhất của dataclass

Một cuộc thảo luận gần đây về thực tiễn tốt nhất của Python dataclass đã khơi mào một cuộc tranh luận rộng rãi trong cộng đồng về cách Python xử lý keyword arguments và nhu cầu về cú pháp ngắn gọn hơn. Cuộc trò chuyện bắt đầu với các khuyến nghị sử dụng keyword-only arguments trong dataclass nhưng nhanh chóng phát triển thành một cuộc xem xét sâu hơn về tính dài dòng của Python so với các ngôn ngữ lập trình khác.

So sánh cú pháp Keyword-Only của Python Dataclass

Dataclass truyền thống:

@dataclass
class MyDataClass:
    x: int
    y: str
    z: bool = True

Dataclass keyword-only (được khuyến nghị):

@dataclass(kw_only=True)
class MyDataClass:
    x: int
    y: str
    z: bool = True

Sự khác biệt trong cách sử dụng:

• Truyền thống: MyDataClass(1, 'foo', False)
• Keyword-only: MyDataClass(x=1, y='foo', z=False)

Vấn đề về tính dài dòng

Các nhà phát triển Python ngày càng cảm thấy bực bội với tính chất lặp lại của keyword arguments, đặc biệt khi tên biến trùng khớp chính xác với tên tham số. Yêu cầu hiện tại phải viết function(x=x, y=y, z=z) khiến nhiều lập trình viên cảm thấy không cần thiết dài dòng, những người đã trải nghiệm các giải pháp thanh lịch hơn trong các ngôn ngữ khác.

Cú pháp viết tắt thuộc tính của JavaScript đã trở thành một điểm đặc biệt khiến các nhà phát triển Python ghen tị. Trong JavaScript, các nhà phát triển có thể đơn giản viết {x, y, z} thay vì {x: x, y: y, z: z} khi tên thuộc tính khớp với tên biến. Tính năng này giảm đáng kể việc lặp lại code và cải thiện khả năng đọc hiểu.

Những nỗ lực giải quyết thất bại

Cộng đồng Python đã cố gắng giải quyết vấn đề này thông qua các kênh chính thức. PEP 736 đã đề xuất một cú pháp viết tắt sử dụng ký hiệu fn(x=, y=, z=), nhưng đề xuất này cuối cùng đã bị từ chối. Nhiều nhà phát triển bày tỏ sự nhẹ nhõm với việc từ chối này, cảm thấy cú pháp được đề xuất khó xử và không cung cấp giải pháp thanh lịch mà họ mong đợi.

Nhìn vào nó, cảm giác tôi có là một đề xuất cú pháp tốt và tiện lợi đã bị từ chối vì tranh cãi về những chi tiết nhỏ.

Một số cách tiếp cận thay thế đã được các thành viên cộng đồng đề xuất. Một số đề xuất sử dụng cú pháp giống OCaml với ký hiệu dấu ngã, trong khi những người khác gợi ý cách tiếp cận tiền tố dấu chấm phẩy của Julia. Tuy nhiên, không có giải pháp thay thế nào trong số này đã thu hút được sự quan tâm đáng kể hoặc được xem xét chính thức.

Các Giải Pháp Cú Pháp Rút Gọn Python Được Đề Xuất

Cách giải quyết tạm thời hiện tại của Python : f(**{x, y, z}) - Sử dụng giải nén từ điển nhưng ít dễ đọc hơn

Các giải pháp tạm thời và giải pháp hiện tại

Mặc dù thiếu cú pháp viết tắt gốc, các nhà phát triển Python đã tìm ra những giải pháp tạm thời sáng tạo. Một cách tiếp cận liên quan đến việc sử dụng dictionary unpacking với f(**{x, y, z}), mặc dù cú pháp này không đặc biệt thanh lịch và có thể gây khó hiểu khi đọc.

Cộng đồng cũng đã chấp nhận TypedDict như một giải pháp để có tài liệu tốt hơn và hỗ trợ IDE khi xử lý keyword arguments. Cách tiếp cận này giúp giải quyết một số điểm khó khăn xung quanh việc sử dụng ** kwargs, đặc biệt trong các thư viện như boto3 nơi tài liệu tham số từng rất kém.

Cuộc tranh luận triết lý rộng hơn

Cuộc thảo luận đã tiết lộ một căng thẳng cơ bản trong triết lý thiết kế của Python. Một số nhà phát triển lập luận rằng sự ưa thích của Python đối với cú pháp rõ ràng, đặc thù thay vì các nguyên tắc có thể kết hợp đang dẫn ngôn ngữ đến sự phức tạp không cần thiết. Họ lo lắng rằng Python đang tiếp cận một tình huống tương tự như C++, nơi cú pháp trở nên rộng lớn đến mức ít nhà phát triển hiểu nó một cách toàn diện.

Những người khác bảo vệ cách tiếp cận hiện tại của Python, lập luận rằng cú pháp rõ ràng và phạm vi thư viện chuẩn toàn diện làm giảm nhu cầu về các phụ thuộc bên ngoài và làm cho code dễ đọc hơn trong dài hạn.

Kết luận

Trong khi yếu tố kích hoạt trực tiếp cho cuộc thảo luận này là thực tiễn tốt nhất của dataclass, nó đã phơi bày những mối quan tâm sâu sắc hơn về sự phát triển và thiết kế cú pháp của Python. Cộng đồng vẫn chia rẽ về việc liệu Python có cần cú pháp ngắn gọn hơn cho các mẫu thông thường hay cách tiếp cận rõ ràng hiện tại phục vụ tốt hơn các mục tiêu về khả năng đọc hiểu và bảo trì của ngôn ngữ. Khi Python tiếp tục phát triển, những cuộc tranh luận này có thể sẽ ảnh hưởng đến các quyết định thiết kế ngôn ngữ trong tương lai và hướng đi của các PEP sắp tới.

Tham khảo: Tip: Use keyword-only arguments in Python dataclasses