On 27 Jun 2024, at 23:48, Aaron Meurer <asmeurer@gmail.com> wrote:
Apparently the reason this happens is that True, False, and None are compared using 'is' in structural pattern matching (see
Please let me stress that the ‘match/case’ snippet was only a concrete example of a situation in which, say ‘f(a)’ gives the correct result when ‘a’ is a ‘float’ instance and breaks down when ‘a’ is a ‘np.foat64’ instance. Now the fact that numpy floats are subclasses of python floats is quite a strong promise that this should never be the case… Realistically this can be solved in a couple of ways. (i) Refactoring ‘f(a)’ so that it is aware of the numpy float quirks… not always possible, especially if ‘f(a)’ belongs to an external package. (ii) Sanitizing numpy floats, lets say by ‘f(a.item())’ in the calling code. (iii) Ensuring that scalar comparisons always return python bools and not ‘np.bool' (i) and (ii) are quite simple user-side workarouns, but sometimes the surprise factor is high, as in the given code snippet. On the contrary (iii) is a radical solution on the library side, but I’m not sure if it’s worth implementing for a few edge cases. In fact ‘b is True’ is an anti-pattern in python, and probably the places in which this behaviour surfaces should be sparse. Stefano