On Thu, Jan 23, 2020 at 8:15 PM Andrew Svetlov
On Thu, Jan 23, 2020 at 5:46 PM Michael Anckaert via Python-Dev
wrote: Hello everyone
I have a usecase where I'm comparing a UUID instance with string quite often. A case where I have to convert the UUID instance to a string using str(uuid_obj), leading to redundant code:
if str(uuid_obj) == uuid: # do stuff...
In my experience I can't find a case where you wouldn't want the implicit conversion to string before comparing a UUID with string. So I would like to propose improving the __eq__ method of UUID to:
def __eq__(self, other): if isinstance(other, UUID): return self.int == other.int elif isinstance(other, str): return str(self) == other return NotImplemented
Based on my testing and experience I don't think this is a breaking change and would be a meaningful change to the way UUID works. Of course please don't hesitate to change my view or point out any flaws in my reasoning.
If other people support this change I'd start the work of creating an issue and PR to get this change implemented.
-1 Implicit type casting leads to hidden errors very often.
I also tend to be against this change, for the same general reason that Andrew gave, but let me try to put that into more concrete terms. In the specific case of UUIDs in the uuid module, equivalent UUIDs can be constructed in various ways using the UUID constructor, including using different string formats. For example, the following strings are considered equivalent UUIDs: "00010203-0405-0607-0809-0a0b0c0d0e0f" "{00010203-0405-0607-0809-0a0b0c0d0e0f}" "000102030405060708090a0b0c0d0e0f" "urn:uuid:00010203-0405-0607-0809-0a0b0c0d0e0f" For more examples, see the uuid module's tests: https://github.com/python/cpython/blob/7142df5ea23b4ce0efb72746b4b3b65414e8d... Using string comparison for UUIDs would be significantly different than what comparing uuid.UUID objects does. Therefore, making UUID.__eq__() fall back to string comparison would be confusing, IMO much more so than it would be helpful. - Tal Einat