bool and int

[Chris Angelico]

On Wed, 25 Jan 2023 at 22:55, <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
>
> On 2023-01-25 at 12:14:50 +1100,
> Chris Angelico <rosuav at gmail.com> wrote:
>
> > On Wed, 25 Jan 2023 at 10:32, <2QdxY4RzWzUUiLuE at potatochowder.com> wrote:
>
> > > The usual complaint is that some people write FORTRAN no matter what
> > > language they're actually using.  Are you writing Python in C#?  ;-)
>
> > But the way I have to write it in C# is a messed-up version of C:
>
> There's your problem:  C# isn't C, it's Java.  Java looks like C, too,
> but it isn't C, either.
>
> > So the problem isn't that I'm trying to write Python in C#, but that
> > I'm trying to write code that would work on pretty much *any other
> > C-family language*, but doesn't work on C#. I could use those
> > techniques in plenty of C-derived and C-inspired languages, but nooooo
> > not in C#, despite looking very much C-inspired. Unfortunately the
> > truth is that C# is not *actually* C-inspired; it's really Microsoft
> > Java, so it has all the stupidities of Java:
>
> There.  Even ChrisA agrees with me.  ;-)
>
> So, I think what you're trying to say is that you prefer the razor sharp
> quality of truthiness to the zen of explicit being better than implicit.

Not sure what you mean here. If you want to bring this back to the Zen
of Python, I would reference "practicality beats purity". We can do
arithmetic on integers and floats without having to explicitly cast
one to the other, because there's really no point in distinguishing
them. We can do that with booleans and other types, too.

> To bring this back to Python (sorry), blurring the line between booleans
> and integers is an old machine language trick, born of the days when we
> measured memory in bytes (and large sums of cash!) rather than gigs[0].
> In Python3, there's no more reason to use a boolean value as integer
> (whether to accumulate values or to test a value against zero) as there
> is to use a string (e.g., from an HTML form) as an integer.

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.

> > But this is hardly a Python-versus-C# thing; it's Java versus most of
> > the rest of the world, and C# feigns to be part of the C style while
> > retaining the limitations of Java.
>
> IMO, the problem started when Java tried to be too much like C to
> attract (or should I say "trap"?) C developers.

Maybe. No idea. In any case, Java's restrictiveness is VERY different
from the way Python works (for instance, operator overloading, the way
strings are handled, etc), and I don't think people here want the
shackles of Java.

> > (My apologies if the Java entries look synthetic. It's because they
> > are, and that's a consequence of me not having ANY reason to write
> > Java code in, like, ever. In fact, I had to go and install a JDK just
> > to confirm that Java really did have these limitations.)
>
> They used Java at my last job (as in, the last job I had before I
> retired), and it was absolutely awful, for any number of reasons, the
> gymnastics (on many levels) required to support "primitive types" being
> one of them.

Yeah. "Primitive types" being different from "boxed types" is an
unnecessary and arbitrary distinction, like between types and classes,
or old-style classes and those that subclass object. Neither is needed
in modern Python, neither is beneficial.

Keeping bool as a subclass of int has never been in dispute. Nor has
the treatment of other types in a boolean context. I can't find
anything in the Python 3000 proposals that ever even suggested
changing either; the best I can find is this reference in PEP 285
which rejected the notions:

"""
Should we strive to eliminate non-Boolean operations on bools in the
future, through suitable warnings, so that for example True+1 would
eventually (in Python 3000) be illegal?

=> No.

Should we strive to require that Boolean operations (like “if”, “and”,
“not”) have a bool as an argument in the future, so that for example
“if []:” would become illegal and would have to be written as “if
bool([]):” ???

=> No!!!
"""

See: https://peps.python.org/pep-0285/

C# is a pain to work with because it fails on these points of
practicality. I'm morbidly curious as to how C# fanatics justify this
sort of thing, given that so many languages just DTRT without needing
to be told.

ChrisA