On 5/3/20 8:40 AM, Ahmed Amr wrote:
Thanks, I do appreciate all the discussion here about that.
Initially, I was thinking about having lists/arrays/tuples match the behavior of other instances in python that compare across their types like: 1) Sets (instances of set or frozenset) can be compared within and across their types As Dominic mentioned. 2) Numeric types do compare across their types along with fractions.Fraction and decimal.Decimal. 3) Binary Sequences( instances of bytes or bytearray) can be compared within and across their types (All points above stated in python reference in https://docs.python.org/3/reference/expressions.html)
but after the discussion here, I think backword compatibility dominates for sure against that, Thanks!
I think the issue is that the set/frozen set distinction (and bytes/bytes array) is a much finer distinction than between arbitrary sequence types, as it is primarily just a change of mutability (and hash-ability), and all the Numeric types are really just slight different abstractions of the same basic set of values (or subsets thereof). The various containers don't have the same concept that they are essentially representing the same 'thing' with just a change in representation to control the types sort of numbers they can express and what sort of numeric errors the might contain (so two representations that map to the same abstract number make sense to be equal) Different types of sequences are more different in what they likely represent, so it is less natural for different sequences of the same value to be thought of as always being 'the same' There may be enough cases where that equality is reasonable, that having a 'standard' function to perform that comparison might make sense, it just isn't likely to be spelled ==. There are several questions on how to do thing that might need to be explored, Should the ignoring of sequence type be recurcively ignored or not, i.e. is [1, [2, 3]] the same as (1, (2, 3)) or not, and are strings just another sequence type, or something more fundamental. This doesn't make it a 'bad' idea, just a bit more complicated and in need of exploration. -- Richard Damon