Trình trang trí cho phương thức lớp python

Tại sao nó lại khó thế này?

Hai trình trang trí [

@classmethod
@synchronized[lock]
def foo[cls]:
    pass

@classmethod
@synchronized[lock]
def foo[cls]:
    pass

• Bất đồng về vị trí của “tuyên bố ý định”. Hầu hết mọi người đều đồng ý rằng việc trang trí/chuyển đổi một chức năng ở cuối định nghĩa của nó là không tối ưu. Ngoài ra, dường như không có sự đồng thuận rõ ràng về nơi đặt thông tin này
• Ràng buộc cú pháp. Python là một ngôn ngữ đơn giản về mặt cú pháp với các ràng buộc khá chặt chẽ về những gì có thể và không thể thực hiện được nếu không “làm rối tung mọi thứ lên” [cả về mặt trực quan và liên quan đến trình phân tích cú pháp ngôn ngữ]. Không có cách rõ ràng nào để cấu trúc thông tin này sao cho những người mới làm quen với khái niệm này sẽ nghĩ, “Ồ, tôi biết bạn đang làm gì. ” Điều tốt nhất có thể là ngăn người dùng mới tạo ra một mô hình tinh thần cực kỳ sai lầm về ý nghĩa của cú pháp
• Nhìn chung không quen thuộc với khái niệm. Đối với những người đã từng làm quen với đại số [hoặc thậm chí là số học cơ bản] hoặc đã sử dụng ít nhất một ngôn ngữ lập trình khác, phần lớn Python là trực quan. Rất ít người có bất kỳ kinh nghiệm nào với khái niệm decorator trước khi bắt gặp nó trong Python. Không có meme tồn tại mạnh mẽ nào có thể nắm bắt được khái niệm này
• Các cuộc thảo luận về cú pháp nói chung dường như gây ra nhiều tranh cãi hơn hầu hết mọi thứ khác. Độc giả được chỉ đến các cuộc thảo luận của nhà điều hành ternary được liên kết với PEP 308 để biết thêm ví dụ về điều này

Vị trí trang trí

Điểm cú pháp đầu tiên là vị trí của các bộ trang trí. Đối với các ví dụ sau, chúng tôi sử dụng @syntax được sử dụng trong 2. 4a2

Các bộ trang trí trước câu lệnh def là lựa chọn thay thế đầu tiên và cú pháp được sử dụng trong 2. 4a2

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

Đã có một số ý kiến ​​phản đối về vị trí này – lý do chính là đây là trường hợp Python thực sự đầu tiên mà một dòng mã có ảnh hưởng đến dòng tiếp theo. Cú pháp có sẵn trong 2. 4a3 yêu cầu một bộ trang trí trên mỗi dòng [trong a2, nhiều bộ trang trí có thể được chỉ định trên cùng một dòng] và quyết định cuối cùng cho 2. 4 cuối cùng ở lại một trang trí trên mỗi dòng

Mọi người cũng phàn nàn rằng cú pháp nhanh chóng trở nên khó sử dụng khi sử dụng nhiều bộ trang trí. Tuy nhiên, vấn đề được đưa ra là khả năng một số lượng lớn các bộ trang trí được sử dụng trên một chức năng duy nhất là nhỏ và do đó đây không phải là một vấn đề lớn.

Một số ưu điểm của hình thức này là các trình trang trí sống bên ngoài phần thân phương thức – rõ ràng chúng được thực thi tại thời điểm hàm được xác định

Một ưu điểm khác là tiền tố cho định nghĩa hàm phù hợp với ý tưởng biết về sự thay đổi đối với ngữ nghĩa của mã trước chính mã đó, do đó bạn biết cách diễn giải đúng ngữ nghĩa của mã mà không cần phải quay lại và thay đổi nhận thức ban đầu của mình nếu

Guido quyết định rằng anh ấy muốn có các bộ trang trí trên hàng trước 'def', vì có cảm giác rằng một danh sách đối số dài có nghĩa là các bộ trang trí sẽ bị 'ẩn'

Dạng thứ hai là các bộ trang trí giữa def và tên hàm hoặc tên hàm và danh sách đối số

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

Có một số phản đối đối với hình thức này. Đầu tiên là nó dễ dàng phá vỡ 'tính khả dụng' của nguồn - bạn không còn có thể tìm kiếm 'def foo[' và tìm định nghĩa của hàm. Phản đối thứ hai, nghiêm trọng hơn, là trong trường hợp có nhiều trình trang trí, cú pháp sẽ cực kỳ khó sử dụng

Hình thức tiếp theo, đã có một số người ủng hộ mạnh mẽ, là đặt các bộ trang trí giữa danh sách đối số và dấu

@dec2
@dec1
def func[arg1, arg2, ...]:
    pass

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

Guido đã tóm tắt các lập luận chống lại biểu mẫu này [nhiều trong số đó cũng áp dụng cho biểu mẫu trước đó] như

• nó ẩn thông tin quan trọng [e. g. rằng nó là một phương thức tĩnh] sau chữ ký, nơi nó dễ bị bỏ qua
• rất dễ bỏ lỡ quá trình chuyển đổi giữa danh sách đối số dài và danh sách trang trí dài
• thật khó để cắt và dán danh sách trang trí để sử dụng lại, bởi vì nó bắt đầu và kết thúc ở giữa một dòng

Hình thức tiếp theo là cú pháp trang trí đi vào bên trong thân phương thức ngay từ đầu, ở cùng một vị trí mà các chuỗi tài liệu hiện đang hoạt động

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

Sự phản đối chính đối với biểu mẫu này là nó yêu cầu "nhìn trộm bên trong" thân phương thức để xác định các bộ trang trí. Ngoài ra, mặc dù mã nằm trong thân phương thức nhưng nó không được thực thi khi phương thức được chạy. Guido cảm thấy rằng chuỗi tài liệu không phải là một ví dụ phản biện tốt và rất có thể trình trang trí 'chuỗi tài liệu' có thể giúp di chuyển chuỗi tài liệu ra bên ngoài thân hàm

Hình thức cuối cùng là một khối mới bao quanh mã của phương thức. Đối với ví dụ này, chúng tôi sẽ sử dụng từ khóa 'trang trí', vì nó không hợp lý với @syntax

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

Hình thức này sẽ dẫn đến thụt đầu dòng không nhất quán cho các phương pháp trang trí và không trang trí. Ngoài ra, phần thân của phương thức được trang trí sẽ bắt đầu ba mức thụt lề trong

biểu mẫu cú pháp

• @dec2
  @dec1
  def func[arg1, arg2, ...]:
      pass
  

  4

  def foo[cls]:
      pass
  foo = synchronized[lock][foo]
  foo = classmethod[foo]
  

  6

  Các phản đối chính đối với cú pháp này là ký hiệu @ hiện không được sử dụng trong Python [và được sử dụng trong cả IPython và Leo] và ký hiệu @ không có ý nghĩa. Một phản đối khác là điều này "lãng phí" một ký tự hiện không được sử dụng [từ một bộ giới hạn] vào một thứ không được coi là mục đích sử dụng chính

• @dec2
  @dec1
  def func[arg1, arg2, ...]:
      pass
  

  5

  def foo[cls]:
      pass
  foo = synchronized[lock][foo]
  foo = classmethod[foo]
  

  3

  Đây là một biến thể của cú pháp @decorator – nó có ưu điểm là không phá vỡ IPython và Leo. Nhược điểm chính của nó so với @syntax là. biểu tượng trông giống cả chữ I viết hoa và chữ l viết thường

• cú pháp liệt kê

  def foo[cls]:
      pass
  foo = synchronized[lock][foo]
  foo = classmethod[foo]
  

  4

  Sự phản đối chính đối với cú pháp danh sách là nó hiện có nghĩa [khi được sử dụng ở dạng trước phương thức]. Nó cũng thiếu bất kỳ dấu hiệu nào cho thấy biểu thức là một trang trí

• cú pháp liệt kê sử dụng các dấu ngoặc khác [

  @dec2
  @dec1
  def func[arg1, arg2, ...]:
      pass
  

  6,

  @dec2
  @dec1
  def func[arg1, arg2, ...]:
      pass
  

  7,…]

  def foo[cls]:
      pass
  foo = synchronized[lock][foo]
  foo = classmethod[foo]
  

  5

  None of these alternatives gained much traction. The alternatives which involve square brackets only serve to make it obvious that the decorator construct is not a list. They do nothing to make parsing any easier. The ‘’ alternative presents parsing problems because ‘’ already parse as un-paired. They present a further parsing ambiguity because a right angle bracket might be a greater than symbol instead of a closer for the decorators.

• @dec2
  @dec1
  def func[arg1, arg2, ...]:
      pass
  

  8

  Đề xuất của

  @dec2
  @dec1
  def func[arg1, arg2, ...]:
      pass
  

  8 là không có cú pháp mới nào được triển khai – thay vào đó là một chức năng kỳ diệu sử dụng nội quan để thao tác chức năng sau. Cả Jp Calderone và Philip Eby đều tạo ra các chức năng thực hiện điều này. Guido đã khá kiên quyết phản đối điều này – không có cú pháp mới, tính kỳ diệu của một chức năng như thế này là cực kỳ cao

  Sử dụng các chức năng với “hành động từ xa” thông qua sys. settraceback có thể ổn đối với một tính năng tối nghĩa không thể có bất kỳ cách nào khác nhưng không đáng để thay đổi ngôn ngữ, nhưng đó không phải là tình huống dành cho người trang trí. Quan điểm phổ biến ở đây là các trình trang trí cần được thêm vào như một tính năng cú pháp để tránh các sự cố với ký hiệu hậu tố được sử dụng trong 2. 2 và 2. 3. Các công cụ trang trí dự kiến ​​sẽ trở thành một tính năng ngôn ngữ mới quan trọng và thiết kế của chúng cần hướng tới tương lai, không bị hạn chế bởi những gì có thể triển khai trong 2. 3

• từ khóa mới [và chặn]

  Ý tưởng này là sự thay thế đồng thuận từ comp. lang thang. python [thêm về điều này trong Đồng thuận cộng đồng bên dưới. ] Robert Brewer đã viết một tài liệu đề xuất J2 chi tiết phác thảo các lập luận ủng hộ biểu mẫu này. Các vấn đề ban đầu với hình thức này là

  • Nó yêu cầu một từ khóa mới và do đó, một câu lệnh

    def foo[cls]:
        pass
    foo = synchronized[lock][foo]
    foo = classmethod[foo]
    

    00
  • Việc lựa chọn từ khóa gây tranh cãi. Tuy nhiên,

    def foo[cls]:
        pass
    foo = synchronized[lock][foo]
    foo = classmethod[foo]
    

    01 nổi lên như một lựa chọn đồng thuận và được sử dụng trong đề xuất và triển khai
  • Dạng từ khóa/khối tạo ra thứ gì đó trông giống như một khối mã bình thường, nhưng không phải. Nỗ lực sử dụng các câu lệnh trong khối này sẽ gây ra lỗi cú pháp, có thể gây nhầm lẫn cho người dùng

  Vài ngày sau, Guido từ chối đề xuất này với hai lý do chính, thứ nhất

  … dạng cú pháp của một khối thụt vào gợi ý mạnh mẽ rằng nội dung của nó phải là một chuỗi các câu lệnh, nhưng thực tế không phải vậy – chỉ các biểu thức mới được phép và có một “sự thu thập” ngầm các biểu thức này cho đến khi chúng có thể được áp dụng . …

  và thứ hai

  … từ khóa bắt đầu dòng đứng đầu một khối thu hút rất nhiều sự chú ý đến nó. Điều này đúng với “if”, “while”, “for”, “try”, “def” và “class”. Nhưng từ khóa “sử dụng” [hoặc bất kỳ từ khóa nào khác ở vị trí của nó] không xứng đáng với sự chú ý đó; . …

  Mời độc giả xem toàn văn phản hồi

• Các chứng từ khác

  Có rất nhiều biến thể và đề xuất khác trên trang wiki

Tại sao @?

Có một số lịch sử trong Java sử dụng @ ban đầu làm điểm đánh dấu trong các nhận xét Javadoc và sau đó trong Java 1. 5 cho các chú thích, tương tự như các trình trang trí Python. Thực tế là @ trước đây không được sử dụng làm mã thông báo trong Python cũng có nghĩa là rõ ràng là không có khả năng mã như vậy được phân tích cú pháp bởi phiên bản Python cũ hơn, dẫn đến các lỗi ngữ nghĩa có thể tinh vi. Điều đó cũng có nghĩa là sự mơ hồ về những gì là một trang trí và những gì không được loại bỏ. Điều đó nói rằng, @ vẫn là một lựa chọn khá độc đoán. Một số đã đề nghị sử dụng. thay thế

Đối với các tùy chọn cú pháp sử dụng cú pháp giống như danh sách [bất kể nó xuất hiện ở đâu] để chỉ định các trình trang trí, một vài lựa chọn thay thế đã được đề xuất.

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

@dec2
@dec1
def func[arg1, arg2, ...]:
    pass

Đồng thuận cộng đồng

Phần này ghi lại cú pháp J2 bị từ chối và được đưa vào để hoàn thiện lịch sử

Sự đồng thuận nổi lên trên comp. lang thang. python là cú pháp J2 được đề xuất ["J2" là cách nó được tham chiếu trên trang wiki PythonDecorators]. từ khóa mới

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

def foo[cls]:
    pass
foo = synchronized[lock][foo]
foo = classmethod[foo]

Các đối số chính cho cú pháp này thuộc học thuyết "tính dễ đọc". Tóm lại, chúng là

• Một bộ tốt hơn nhiều @lines. Từ khóa và khối

  def foo[cls]:
      pass
  foo = synchronized[lock][foo]
  foo = classmethod[foo]
  

  01 chuyển đổi câu lệnh

  def foo[cls]:
      pass
  foo = synchronized[lock][foo]
  foo = classmethod[foo]
  

  08 khối đơn thành cấu trúc phức hợp nhiều khối, giống như thử/cuối cùng và các lệnh khác
• Từ khóa tốt hơn dấu chấm câu cho mã thông báo mới. Một từ khóa phù hợp với việc sử dụng mã thông báo hiện có. Không cần loại mã thông báo mới. Một từ khóa phân biệt các trình trang trí Python với các chú thích Java và. Thuộc tính ròng, là những con thú khác nhau đáng kể

Robert Brewer đã viết một đề xuất chi tiết cho biểu mẫu này và Michael Sparks đã tạo ra một bản vá

Như đã lưu ý trước đây, Guido đã từ chối biểu mẫu này, nêu rõ các vấn đề của anh ấy với nó trong một thông báo tới python-dev và comp. lang thang. con trăn