__lt__ thay vì __cmp__

Question

Python 2.x có hai cách để quá tải toán tử so sánh, __cmp__ hoặc "toán tử so sánh phong phú" chẳng hạn như __lt__. Quá tải so sánh phong phú được cho là được ưu tiên, nhưng tại sao lại như vậy?

Các toán tử so sánh phong phú đơn giản hơn để thực hiện từng thao tác, nhưng bạn phải triển khai một vài trong số chúng với logic gần như giống hệt nhau. Tuy nhiên, nếu bạn có thể sử dụng được xây dựng trong cmp và tuple đặt hàng, sau đó __cmp__ bị khá đơn giản và đáp ứng tất cả các so sánh:

class A(object): 
    def __init__(self, name, age, other): 
    self.name = name 
    self.age = age 
    self.other = other 
    def __cmp__(self, other): 
    assert isinstance(other, A) # assumption for this example 
    return cmp((self.name, self.age, self.other), 
       (other.name, other.age, other.other)) 

đơn giản này dường như để đáp ứng nhu cầu của tôi tốt hơn nhiều so với quá tải tất cả 6 của những người giàu (!) so sánh. (Tuy nhiên, bạn có thể nhận được nó xuống "chỉ" 4 nếu bạn dựa vào "hành vi hoán đổi"/phản ánh hành vi, nhưng điều đó dẫn đến sự gia tăng ròng của biến chứng, theo ý kiến ​​khiêm tốn của tôi.)

Có bất kỳ những cạm bẫy không lường trước được Tôi cần phải được biết nếu tôi chỉ quá tải __cmp__?

Tôi hiểu các nhân viên <, <=, ==, v.v. có thể bị quá tải vì các mục đích khác và có thể trả lại bất kỳ đối tượng nào họ thích. Tôi không hỏi về giá trị của cách tiếp cận đó, nhưng chỉ về sự khác biệt khi sử dụng các toán tử này để so sánh theo cùng một nghĩa mà chúng có ý nghĩa đối với các con số.

Cập nhật: Vì Christopher pointed out, cmp sẽ biến mất trong 3.x. Có bất kỳ lựa chọn thay thế nào thực hiện so sánh triển khai dễ dàng như trên __cmp__ không?

Answer 1

Vâng, thật dễ dàng để thực hiện mọi thứ về mặt, ví dụ: __lt__ với một lớp mixin (hoặc một metaclass, hoặc một trang trí lớp nếu hương vị của bạn chạy theo cách đó).

Ví dụ:

class ComparableMixin: 
    def __eq__(self, other): 
    return not self<other and not other<self 
    def __ne__(self, other): 
    return self<other or other<self 
    def __gt__(self, other): 
    return other<self 
    def __ge__(self, other): 
    return not self<other 
    def __le__(self, other): 
    return not other<self 

Bây giờ lớp học của bạn có thể xác định chỉ __lt__ và nhân kế thừa từ ComparableMixin (sau khi bất cứ điều gì các căn cứ khác nó cần, nếu có). Một trình trang trí lớp sẽ khá giống nhau, chỉ cần chèn các hàm tương tự như các thuộc tính của lớp mới đó là trang trí (kết quả có thể nhanh hơn về mặt thời gian trong thời gian chạy, với chi phí bằng nhau về mặt bộ nhớ). Tất nhiên, nếu lớp học của bạn có một số cách thực hiện nhanh nhất (ví dụ) __eq__ và __ne__, cần xác định chúng trực tiếp để các phiên bản mixin không sử dụng (ví dụ, trường hợp là dict) - trong thực tế __ne__ cũng có thể được xác định để tạo điều kiện đó như:

def __ne__(self, other): 
    return not self == other 

nhưng trong đoạn mã trên tôi muốn giữ đối xứng hài lòng chỉ sử dụng < ;-). Vì lý do tại sao __cmp__ phải đi, vì chúng tôi đã làm có __lt__ và bạn bè, tại sao nên giữ một cách khác để thực hiện chính xác điều tương tự? Nó chỉ là quá nhiều trọng lượng chết trong mọi thời gian chạy Python (Classic, Jython, IronPython, PyPy, ...). Mã số chắc chắn sẽ không có lỗi là mã không có ở đó - nguyên tắc của Python là phải có một cách rõ ràng lý tưởng để thực hiện một nhiệm vụ (C có nguyên tắc tương tự trong "Spirit of C" phần của tiêu chuẩn ISO, btw).

Điều này không có nghĩa là chúng ta không thể làm mọi thứ (ví dụ, gần tương đương giữa mixin và trang trí lớp cho một số công dụng), nhưng chắc chắn hiện có nghĩa là chúng tôi không thích mang theo mã trong các trình biên dịch và/hoặc runtimes mà dư thừa tồn tại chỉ để hỗ trợ nhiều phương pháp tương đương để thực hiện chính xác cùng một nhiệm vụ.

Chỉnh sửa thêm: thực tế còn có cách tốt hơn để cung cấp so sánh và băm cho nhiều lớp, bao gồm cả câu hỏi trong câu hỏi - phương pháp __key__, như tôi đã đề cập trong nhận xét của tôi cho câu hỏi. Vì tôi không bao giờ có xung quanh để viết PEP cho nó, bạn đang phải thực hiện nó với một Mixin (& c) nếu bạn thích nó:

class KeyedMixin: 
    def __lt__(self, other): 
    return self.__key__() < other.__key__() 
    # and so on for other comparators, as above, plus: 
    def __hash__(self): 
    return hash(self.__key__()) 

Đó là một trường hợp rất phổ biến để so sánh của một ví dụ với các trường hợp khác để đun sôi xuống để so sánh một tuple cho mỗi một vài trường - và sau đó, băm nên được triển khai trên cùng một cơ sở. Các địa chỉ phương thức đặc biệt __key__ cần trực tiếp.

Answer 2

này được bao phủ bởi PEP 207 - Rich Comparisons

Ngoài ra, __cmp__ biến mất trong python 3.0. (Lưu ý rằng nó không có trên http://docs.python.org/3.0/reference/datamodel.html nhưng nó là trên http://docs.python.org/2.7/reference/datamodel.html)

Answer 3

(Đã chỉnh sửa 17/17 để nhận xét.)

Tôi đã thử câu trả lời mixin tương tự ở trên. Tôi gặp rắc rối với "Không". Đây là một phiên bản sửa đổi xử lý so sánh bình đẳng với "Không". (Tôi thấy không có lý do gì để bận tâm với sự so sánh bất bình đẳng với Không như ngữ nghĩa thiếu):

class ComparableMixin(object): 

    def __eq__(self, other): 
     if not isinstance(other, type(self)): 
      return NotImplemented 
     else: 
      return not self<other and not other<self 

    def __ne__(self, other): 
     return not __eq__(self, other) 

    def __gt__(self, other): 
     if not isinstance(other, type(self)): 
      return NotImplemented 
     else: 
      return other<self 

    def __ge__(self, other): 
     if not isinstance(other, type(self)): 
      return NotImplemented 
     else: 
      return not self<other 

    def __le__(self, other): 
     if not isinstance(other, type(self)): 
      return NotImplemented 
     else: 
      return not other<self  

Answer 4

Để đơn giản hóa trường hợp này có một trang trí lớp bằng Python 2.7 +/3.2 +, functools.total_ordering, có thể được sử dụng để thực hiện những gì Alex gợi ý. Ví dụ từ các tài liệu:

@total_ordering 
class Student: 
    def __eq__(self, other): 
     return ((self.lastname.lower(), self.firstname.lower()) == 
       (other.lastname.lower(), other.firstname.lower())) 
    def __lt__(self, other): 
     return ((self.lastname.lower(), self.firstname.lower()) < 
       (other.lastname.lower(), other.firstname.lower())) 

Answer 5

Lấy cảm hứng từ ComparableMixin & KeyedMixin câu trả lời Alex Martelli, tôi đã đưa ra mixin sau. Nó cho phép bạn thực hiện một phương thức _compare_to() đơn, sử dụng các so sánh dựa trên khóa tương tự như KeyedMixin, nhưng cho phép lớp của bạn chọn khóa so sánh hiệu quả nhất dựa trên loại other. (Lưu ý rằng mixin này không giúp ích nhiều cho các đối tượng có thể được kiểm tra về sự bình đẳng nhưng không được đặt hàng).

class ComparableMixin(object): 
    """mixin which implements rich comparison operators in terms of a single _compare_to() helper""" 

    def _compare_to(self, other): 
     """return keys to compare self to other. 

     if self and other are comparable, this function 
     should return ``(self key, other key)``. 
     if they aren't, it should return ``None`` instead. 
     """ 
     raise NotImplementedError("_compare_to() must be implemented by subclass") 

    def __eq__(self, other): 
     keys = self._compare_to(other) 
     return keys[0] == keys[1] if keys else NotImplemented 

    def __ne__(self, other): 
     return not self == other 

    def __lt__(self, other): 
     keys = self._compare_to(other) 
     return keys[0] < keys[1] if keys else NotImplemented 

    def __le__(self, other): 
     keys = self._compare_to(other) 
     return keys[0] <= keys[1] if keys else NotImplemented 

    def __gt__(self, other): 
     keys = self._compare_to(other) 
     return keys[0] > keys[1] if keys else NotImplemented 

    def __ge__(self, other): 
     keys = self._compare_to(other) 
     return keys[0] >= keys[1] if keys else NotImplemented