On Thu, 26 Jan 2023 at 03:19, <2qdxy4rzwzuui...@potatochowder.com> wrote: > > Strongly disagree. There is PLENTY of practical value in using > > booleans as numbers. This is nothing to do with counting bytes, and > > everything to do with how useful it is in practice. > > IMO, the difference in readability between > > autothrust_last_dv *= AT_mode == AT.Idle; > > and > > if(AT_mode != AT.Idle) > autothrust_last_dv = 0; > > outweighs the practicality, whether C, C#, Java, or Python (ignoring the > insignificant differences in syntax).
Yeah, that example was completely synthetic and not really a good showcase. But what often comes up is either multiplying a string by a boolean (equivalent to "have this string if this is true") or subscripting something with a boolean. > I could argue that the only reason the first one is readable at all is > that we've both been exposed to languages where fanatics assume that > True is 1 and False is 0. I'm fine with any definition as long as it's dependable. > I've also written low-level code with > hardware fanatics who insist that True is 0 and False is -1 (or 255, > depending on how much math they know). BASIC was like that too, although it (at least, the versions I used in my childhood) didn't have "True" and "False", you just got the actual values -1 and 0. They were the other way around compared to what you're saying here though. > In a posix shell script (or a > program that knows it might be run inside such a script), 0 is "true" > and non-zero is "false." And that's a consequence of a system wherein there is only one concept of "success", but many concepts of "failure". Whoever devised that system was clearly a pessimist :) > My point here is that you have to understand > how to work within whatever environment you're using, and that future > programmers (and future you!) will have to deal with your choices > regardless of their background, biases, and preferences. That's always the case, though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list