It's not my proposal, and I don't know if I'm for it or against it, but I thought I'd mention it because I think it's interesting. The observation is that if an object is immutable, there's no legitimate reason to know whether it's distinct from another object with the same type and value. Therefore, the proposal is to change the definition of "is" as follows: 1) Unless x and y are both immutable, the meaning of "x is y" remains as it has always been. 2) If x and y have different types, "x is y" is false (as ever). 3) If x and y are scalars, the definition of "x is y" is changed to mean "x == y" 4) Otherwise x and y are immutable collections of the same type, in which case "x is y" is true if and only if every component of x is the corresponding component of y (i.e. yields True when compared using "is"). This change would clear up some seeming anomalies, such as: >>> 1000 is 1000 True >>> x = 1000 >>> y = 1000 >>> x is y False >>> x = 42 >>> y = 42 >>> x is y True The only disadvantage I can think of is that some comparisons might become much slower (for example, using "is" to compare two long strings that share a long common prefix). However, I have a hard time understanding why anyone would actually want to use "is" on immutable objects, and if one wants to force a true object-identity comparison, one can always use id(x)==id(y). So my question to the more experienced members of this group: Is this idea worth considering? If not, why not? (I'm partly expecting a response of "It's not Pythonic," but I don't actually know why not).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4