The elegance and flaws of the lovely Python:python, part 1th

In this article, I'm going to discuss the less compelling features that have been added in recent Python versions, and I'll analyze which improvements have real value and which features just unnecessarily add complexity. I want to point out to all programmers who are not always using Python what is truly valuable. This includes programmers in other languages and scientists who only use programming as a sideline. I will provide a solution when I encounter some problems.

Can not compare the trouble

There have been some strange changes between Python 2.0 and Python 2.1. Objects that can be compared before are thrown with exceptions when they compare. Specifically, complex numbers cannot be compared with other digits, including other complex numbers and integers, floating-point numbers, and long integers. In fact, you might encounter this problem before comparing a Unicode string with a text string, but that only happens in extreme cases.

I think these changes are bizarre and unnecessary. In the golden age of 1.5.2, the unequal operator always returns a result regardless of what object is compared. Of course, the results are not necessarily meaningful-for example, the comparison of strings and floating-point numbers is meaningless. But at least we always get a consistent result.

After these changes, some Python proponents argue that it is a good thing not to allow unequal comparisons of different types of objects, and that this comparison can only be made after the custom comparison function has been defined. I think it's really tricky to write custom comparison functions when dealing with custom classes and multiple inheritance. In addition, it is not convenient to compare floating-point numbers, integers, and long integers (such as decimal). However, it may be possible to define a reasonable rule.

However, regardless of what rules are defined, it is very different from what Python has done in the past. The present situation is that the comparison behavior is irregular, and even knowing the type of the objects being compared cannot determine whether they are comparable (and unequal are not transitive or closed):

Listing 1. Whether the comparison succeeds depends on the type and value

>>> map(type, (u1, s1, s2))
[<type 'unicode'>, <type 'str'>, <type 'str'>]
>>> u1 < s1
True
>>> s1 < s2
True
>>> u1 < s2
UnicodeDecodeError: 'ascii' codec can't decode byte 0xf0 in position 0:
　　ordinal not in range(128)
>>> map(type, (n, j, u1))
[<type 'int'>, <type 'complex'>, <type 'unicode'>]
>>> n < u1
True
>>> j < u1
True
>>> n < j
TypeError: no ordering relation is defined for complex numbers

Worse still, complex numbers cannot now be compared with most numeric values, but absolute inequality can be judged by most non-numeric values. For example, given the purity of the theory, I know that the comparison between 1+1j and 2-3j is meaningless, but why there are the following results:

Listing 2. A startling comparison of results

>>> 2-3j < 'spam'
True
>>> 4+0j < decimal.Decimal('3.14')
True
>>> 4+0j < 5+0j
TypeError: no ordering relation is defined for complex numbers

Theoretically, there is nothing "pure" to say.