5 ms·

I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as True = 1 False = 0 the

I remember reading that in early versions of Python there was no built in True and False. Each user would implement this themselves as True = 1 False = 0 then later these got added to the language. In Python 2 you could still reassign and swap them so that 'if False' was actually true! True, False = False, True Python 3 you could no longer reassign them.

LPisGood 1mo ago
It is certainly the case that isinstance(True, int) returns True, even today.
- jp_sc 1mo ago
  I got a bug for not remembering it, a couple of years ago: https://jpscaletti.com/p/8/true-false-one-and-zero https://jpscaletti.com/p/8/true-false-one-and-zero
  - chlorelladevil 1mo ago
    Hmm. Having read your post, surely the bug is having a function where set(foo, false) removes foo entirely. What if you want foo to have the value False? Even besides the unintended behaviour where 0 is coerced to a boolean value, this function seems poorly designed.
    - jp_sc 1mo ago
      I don't remember the specifics, it might have been a simplification for the example
Animats 1mo ago
Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True. Common language design boners: - Not building in strings. That's now in the past. Everybody has strings. (Well, C...) - Not building in multidimensional arrays of the numeric types. Everything that number-crunches needs them, and having multiple definitions is Not Fun and may lead to expensive re-copying between different libraries. This is an enormous blind spot in language design. It's one of the reasons FORTRAN, which has good multidimensional numeric arrays, is still often used for number-crunching. - Not standardizing the small vectors (vec2, vec3, vec4) and their matrix friends. Graphics code depends on these, and it's really annoying if there are multiple slightly incompatible implementations. Especially since GPUs have hardware for those types, and you want CPU and GPU to use the same representations. - Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it. Most useful languages acquire these features, but, when they come in late, there are multiple similar implementations, and libraries made incompatible by depending on different implementations. (Amusingly, when Second Life switched from Linden Scripting Language to Luau, they initially had True, TRUE, and true all in use, as different types with different semantics. I was able to persuade the devs to unify the boolean types.)
- dwattttt 1mo ago
  > Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it. I'm not sure exactly which features are responsible (I'm inclined to blame templates), but C++'s std::vector<bool> is a rough edge. For those unfamiliar, the standard specifies this vector template in a way that's not compatible with other vectors.
  - Lvl999Noob 1mo ago
    Agreed. Instead of special casing Boolean arrays to be packed, it's better to have standard Boolean arrays and bitarrays as separate types.
    - NekkoDroid 1mo ago
      They should have made `std::bitset<std::dynamic_extent>` what todays `std::vector<bool>` is (actually maybe not, `std::bitset` is fixed sized, just compile time fixed size). While at it also make `std::array<std::dynamic_extent>` a runtime fixed size array.
- DarkUranium 1mo ago
  Vectors & multidimesional arrays are something I'm 100% adding to my language's core. It kind of started with vectors as the very first feature (I was sick & tired of libraries reinventing their own `Point`/`VectorN` in incompatible ways).
- AdamH12113 1mo ago
  Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do. Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.
  - 1mo ago
jamesfinlayson 1mo ago
Yes I remember a friend doing university marking for a beginners programming course years ago and some student had managed to swap True and False making their assignment very wonky.
zahlman 1mo ago
I was surprised TFA didn't mention this, or seemingly know about it.

LPisGood 1mo ago

It is certainly the case that isinstance(True, int) returns True, even today.

jp_sc 1mo ago
I got a bug for not remembering it, a couple of years ago: https://jpscaletti.com/p/8/true-false-one-and-zero https://jpscaletti.com/p/8/true-false-one-and-zero
- chlorelladevil 1mo ago
  Hmm. Having read your post, surely the bug is having a function where set(foo, false) removes foo entirely. What if you want foo to have the value False? Even besides the unintended behaviour where 0 is coerced to a boolean value, this function seems poorly designed.
  - jp_sc 1mo ago
    I don't remember the specifics, it might have been a simplification for the example

Animats 1mo ago

Misery is trying to retrofit "bool", True/False, and nil/null to a language. C had to do that. Python had to do that. Getting those wrong is one of the classic language design mistakes. It seems like treating "True" as a value that equates to 1 will work, but then the special cases get you. Like being able to perform arithmetic on True. Common language design boners: - Not building in strings. That's now in the past. Everybody has strings. (Well, C...) - Not building in multidimensional arrays of the numeric types. Everything that number-crunches needs them, and having multiple definitions is Not Fun and may lead to expensive re-copying between different libraries. This is an enormous blind spot in language design. It's one of the reasons FORTRAN, which has good multidimensional numeric arrays, is still often used for number-crunching. - Not standardizing the small vectors (vec2, vec3, vec4) and their matrix friends. Graphics code depends on these, and it's really annoying if there are multiple slightly incompatible implementations. Especially since GPUs have hardware for those types, and you want CPU and GPU to use the same representations. - Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it. Most useful languages acquire these features, but, when they come in late, there are multiple similar implementations, and libraries made incompatible by depending on different implementations. (Amusingly, when Second Life switched from Linden Scripting Language to Luau, they initially had True, TRUE, and true all in use, as different types with different semantics. I was able to persuade the devs to unify the boolean types.)

dwattttt 1mo ago
> Not having arrays of bits. Pascal had PACKED ARRAY[0..N] of BOOLEAN but that was lost in later languages. It's useful to have that as a language construct, because most modern CPUs have good hardware for dealing with bit strings, and you'd like the compiler to use it. I'm not sure exactly which features are responsible (I'm inclined to blame templates), but C++'s std::vector<bool> is a rough edge. For those unfamiliar, the standard specifies this vector template in a way that's not compatible with other vectors.
- Lvl999Noob 1mo ago
  Agreed. Instead of special casing Boolean arrays to be packed, it's better to have standard Boolean arrays and bitarrays as separate types.
  - NekkoDroid 1mo ago
    They should have made `std::bitset<std::dynamic_extent>` what todays `std::vector<bool>` is (actually maybe not, `std::bitset` is fixed sized, just compile time fixed size). While at it also make `std::array<std::dynamic_extent>` a runtime fixed size array.
DarkUranium 1mo ago
Vectors & multidimesional arrays are something I'm 100% adding to my language's core. It kind of started with vectors as the very first feature (I was sick & tired of libraries reinventing their own `Point`/`VectorN` in incompatible ways).
AdamH12113 1mo ago
Strings are a really weird data type. I'm not sure you can do much better than C strings without implicitly requiring dynamic memory allocation, which C deliberately does not do. Definitely agree on multidimensional arrays. I feel like efficient arrays in general are underrated in high-level language design.
- 1mo ago

jamesfinlayson 1mo ago

Yes I remember a friend doing university marking for a beginners programming course years ago and some student had managed to swap True and False making their assignment very wonky.

zahlman 1mo ago

I was surprised TFA didn't mention this, or seemingly know about it.