Mailing List Archive

1 2  View All
Re: bool and int [ In reply to ]
On Thu, 26 Jan 2023 at 21:53, Weatherby,Gerard <gweatherby@uchc.edu> wrote:
>
> I can’t help but wonder if there exists some Java forum /mailing list going on about how horrible Python is.

Try https://www.reddit.com/r/ProgrammerHumor/ for plenty of people
whining about how horrible Python is.

But along the way, you'll also find people whining about ChatGPT,
reposting memes with minor updates, and sharing the very best (worst?)
of dad jokes.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: RE: bool and int [ In reply to ]
Wow. That was quite a message and an interesting read. Tempted to go
deep and say what I agree and what I disagree with, but there are two
issues: 1) time 2) I will soon be at a disadvantage discussing with
people (you or others) who know more than me (which doesn't make them
right necessarily, but certainly they'll have the upper-hand in a
discussion).

Personally, in the first part of my career I got into the habit of
learning things fast, sometimes superficially I confess, and then get
stuff done hopefully within time and budget. Not the recommended
approach if you need to build software for a nuclear plant. An OK
approach (within reason) if you build websites or custom solutions for
this or that organization and the budget is what it is. After all,
technology moves sooo fast, and what we learn in detail today is bound
to be old and possibly useless 5 years down the road.

Also, I argue that there is value in having familiarity with lots of
different technologies (front-end and back-end) and knowing (or at
lease, having a sense) of how they can all be made play together with an
appreciation of the different challenges and benefits that each domain
offers.

Anyway, everything is equivalent to a Turing machine and IA will screw
everyone, including programmers, eventually.

Thanks again and have a great day

Dino

On 1/25/2023 9:14 PM, avi.e.gross@gmail.com wrote:
> Dino,
>
> There is no such things as a "principle of least surprise" or if you insist
> there is, I can nominate many more such "rules" such as "the principle of
> get out of my way and let me do what I want!"
>
> Computer languages with too many rules are sometimes next to unusable in
> practical situations.
>
> I am neither defending or attacking choices Python or other languages have
> made. I merely observe and agree to use languages carefully and as
> documented.
>
--
https://mail.python.org/mailman/listinfo/python-list
RE: bool and int [ In reply to ]
Gerard,

I am sure there is. I have been on many forums that discuss programming
languages and since nothing is perfect and people differ in many ways, there
is always grumbling and comparison.

If we all agreed and there was only one of something, I suspect we still
would complain and that is precisely why there are generally many variations
as others like their own ideas better.

Python remains a quite decent and useful language, warts and especially
imagined warts and all.

Avi

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Weatherby,Gerard
Sent: Thursday, January 26, 2023 5:52 AM
To: python-list@python.org
Subject: Re: bool and int

I can't help but wonder if there exists some Java forum /mailing list going
on about how horrible Python is.

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on
behalf of rbowman <bowman@montana.com>
Date: Wednesday, January 25, 2023 at 12:25 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: bool and int
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***

On Wed, 25 Jan 2023 06:53:44 -0500, 2QdxY4RzWzUUiLuE wrote:


> 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.

My first brush with Java was around '98 when it was first becoming popular.
To familiarize myself with the AWT I decided to write a simple IDE for the
AVR microcontrollers. What a disaster. The UI wasn't bad but the
instructions for 8-bit processors require a lot of bit fiddling that was
extraordinarily difficult in Java.

Then they came out with Swing and the assumption if the app ran with glacial
slowness you should get a faster machine.

The company I work for has one Java app created around 2000 as a cross
platform solution as people moved to Windows. Originally it ran as an applet
but when that window was slammed shut it became increasingly unwieldy.

For what I'm developing today I used either .NET C# or Python3. The .NET
UI's on Linux aren't quite there yet but back end applications are fine.
PyQt (PySide actually. If there is a way to screw up commercial licensing Qt
will find it) is fine.
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-
list__;!!Cn_UX_p3!iVrdROvxcoNV-GhzezJe8fJSLSAUoPkZHaXF58tWtyogy37PB6b9DH-gIN
gbVLuU64V4RovArDpnC5jjiQ$<https://urldefense.com/v3/__https:/mail.python.org
/mailman/listinfo/python-list__;!!Cn_UX_p3!iVrdROvxcoNV-GhzezJe8fJSLSAUoPkZH
aXF58tWtyogy37PB6b9DH-gINgbVLuU64V4RovArDpnC5jjiQ$>
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On Fri, 27 Jan 2023 at 03:31, rbowman <bowman@montana.com> wrote:
>
> On Thu, 26 Jan 2023 04:10:30 +1100, Chris Angelico wrote:
>
>
> > 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.
>
> I've see header files from people with boolean envy that are something
> like
>
> #define FALSE 0
> #define TRUE ~FALSE
>

Yeah, that's the same logic that BASIC uses: false is zero, and true
is the all-ones integer (which, interpreted as a two's complement
signed number, is -1).

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On 1/25/2023 5:42 PM, Chris Angelico wrote:

>
> Try this (or its equivalent) in as many languages as possible:
>
> x = (1 > 2)
> x == 0
>
> You'll find that x (which has effectively been set to False, or its
> equivalent in any language) will be equal to zero in a very large
> number of languages. Thus, to an experienced programmer, it would
> actually be quite the opposite: having it NOT be a number would be the
> surprising thing!

I thought I had already responded to this, but I can't see it. Weird.

Anyway, straight out of the Chrome DevTools console:
?
x = (1>2)
false

x == 0
true

typeof(x)
'boolean'

typeof(0)
'number'

typeof(x) == 'number'
false

So, you are technically correct, but you can see that JavaScript - which
comes with many gotchas - does not offer this particular one.


--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
Chris Angelico <rosuav@gmail.com> writes:

> On Thu, 26 Jan 2023 at 08:19, Dino <dino@no.spam.ar> wrote:
>>
>> On 1/23/2023 11:22 PM, Dino wrote:
>> > >>> b = True
>> > >>> isinstance(b,bool)
>> > True
>> > >>> isinstance(b,int)
>> > True
>> > >>>
>>
>> ok, I read everything you guys wrote. Everyone's got their reasons
>> obviously, but allow me to observe that there's also something called
>> "principle of least surprise".
>>
>> In my case, it took me some time to figure out where a nasty bug was
>> hidden. Letting a bool be a int is quite a gotcha, no matter how hard
>> the benevolent dictator tries to convince me otherwise!
>>
>
> Try this (or its equivalent) in as many languages as possible:
>
> x = (1 > 2)
> x == 0
>
> You'll find that x (which has effectively been set to False, or its
> equivalent in any language) will be equal to zero in a very large
> number of languages. Thus, to an experienced programmer, it would
> actually be quite the opposite: having it NOT be a number would be the
> surprising thing!

I think the programmer's experience would have to have been rather
narrow to be surprised by x not being treated as a number. I started
with Fortran, Lisp, Pascal and two variants of Algol so I started out
un-surprised by Boolean being a non-arithmetic type. To be surprised by
x (above) /not/ being treated as a number, an experienced programmer
would have had to have avoided a lot of strictly typed languages.

I've just tried Scheme, Haskell, Common Lisp, Ada, Algol-68, go, ML,
Rust, Ruby, Java, Lua, Prolog and Fortran and they all either say "no
way!" or give false for x == 0. Of course these are not random choices,
but it shows that Python's design is very far from universal.

But then this is not a numbers game, anyway. A programmer need only to
have used one or two languages that are rather more strict about types
to find such a thing unsurprising in future.

--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On 2023-01-26 at 12:12:30 -0500,
Dino <dino@no.spam.ar> wrote:

> On 1/25/2023 5:42 PM, Chris Angelico wrote:
>
> >
> > Try this (or its equivalent) in as many languages as possible:
> >
> > x = (1 > 2)
> > x == 0
> >
> > You'll find that x (which has effectively been set to False, or its
> > equivalent in any language) will be equal to zero in a very large
> > number of languages. Thus, to an experienced programmer, it would
> > actually be quite the opposite: having it NOT be a number would be the
> > surprising thing!
>
> I thought I had already responded to this, but I can't see it. Weird.
>
> Anyway, straight out of the Chrome DevTools console:
> ?
> x = (1>2)
> false
>
> x == 0
> true
>
> typeof(x)
> 'boolean'
>
> typeof(0)
> 'number'
>
> typeof(x) == 'number'
> false
>
> So, you are technically correct, but you can see that JavaScript - which
> comes with many gotchas - does not offer this particular one.

When you start a new language, try to start from the beginning. Yes,
you know other languages, to varying degrees, and the language you are
learning is very likely similar, at least superficially, in some way or
another, to one of those other languages. Use that existing knowledge
to the extent that it is useful; be prepared to forget everything you
know.

Python's choice of type hierarchy is not at all uncommon, and it's only
a gotcha if you come in with a predetermined idea of how certain things
"should" work. I've already noted that writing FORTRAN in any language
is a meme.

For a completely different take on booleans, take a look at Python's
logical "and" and "or" operators (*not* the arithmetic "|" and "&"
operators), which only sometimes return an actual boolean value. Then
compare them to the "any" and "all" builtins, which came along much
later. Idiomatic Python uses the right tool for the job *in Python*,
whether or not that same tool is or isn;'t the right tool for the same
job in some other language.

Python is like Lisp in that it (Python) has strong dynamic typing. From
my Common Lisp REPL:

CL-USER> (let ((x (< 1 2)))
(cons x (type-of x)))
(T . BOOLEAN)

CL-USER> (let ((x (> 1 2)))
(cons x (type-of x)))
(NIL . NULL)

In English, the canonical "true" value in Lisp is T, and its type is
BOOLEAN. Likewise, the canonical "false" value in Lisp is NIL, and its
type is NULL. Out of the box, Lisp will not convert T or NIL to a
number.
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On Fri, 27 Jan 2023 at 06:32, Dino <dino@no.spam.ar> wrote:
>
> On 1/25/2023 5:42 PM, Chris Angelico wrote:
>
> >
> > Try this (or its equivalent) in as many languages as possible:
> >
> > x = (1 > 2)
> > x == 0
> >
> > You'll find that x (which has effectively been set to False, or its
> > equivalent in any language) will be equal to zero in a very large
> > number of languages. Thus, to an experienced programmer, it would
> > actually be quite the opposite: having it NOT be a number would be the
> > surprising thing!
>
> I thought I had already responded to this, but I can't see it. Weird.
>
> Anyway, straight out of the Chrome DevTools console:
> ?
> x = (1>2)
> false
>
> x == 0
> true
>
> typeof(x)
> 'boolean'
>
> typeof(0)
> 'number'
>
> typeof(x) == 'number'
> false
>
> So, you are technically correct, but you can see that JavaScript - which
> comes with many gotchas - does not offer this particular one.
>

That's not what I said, though! What you did in JS was the equivalent of this:

>>> type(True) == type(1)
False

which isn't the same as an isinstance check. Instead, try *exactly
what I said*. You'll find that false is equal to zero and true is
equal to one, just like it is in Python.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
RE: RE: bool and int [ In reply to ]
[.Dino has a deliberately invalid email address so sending him anything
privately is not an option.]

Dino,

I would agree with you that for some purposes, you do NOT need to dig deep
into a language to get fairly routine things done. You can often borrow
ideas and code from an online search and hopefully cobble "a" solution
together that works well enough. Of course it may suddenly fall apart. An
example is code written that assumes 4 specific files exist in the current
directory and unconditionally reads them and does stuff and eventually
overwrites some other file with new data. OOPS, what does the program do it
one or more files do not exist in the current directory under those exact
names? Does it check if they exist and exit gracefully, or start throwing
error messages as the code blindly proceeds on trying to change variables
that were never created and so on, and then end with perhaps an emptied file
and ruin lots of things?

Too many examples you get from the internet are a bit like that. They often
just tell you how to do something specific but leave out lots of details
that are a good idea for many kinds of code. And some adjustments you make
may break things and produce a result you trust but that is actually wrong.

So if you find something you don't like about the language, guess what. You
have very little standing if you never learned much more than what it took
to copy some code. You are likely to be told things by others ranging from
suggesting you need to do it another way or that the language is doing
exactly what was designed and suggestions you go back to school and get a
proper education and then the answer may be obvious.

It truly does NOT matter what YOU think should happen unless you point to
documentation that says something else should have happened.

I will skip a lengthier reply but am thinking how some languages use a
boxing/unboxing approach to wrap native "objects" like an integer. In many
cases, your program is allowed to treat this as either a wrapped object or
unboxed as needed and the compiler or interpreter keeps making changes
behind the scenes so you see it as needed. In a sense, Booleans are a
restricted form of integer and are viewed one of several ways. Python goes
many steps further and has a concept of truthy that maps practically
anything to True or False.

The bottom line is not that Python or any language is wrong or right or
great or horrible. It is that based on your own admission, you have not
taken steps to understand more than you have to and thus are in a weak
position to argue anything. Not because any of us are smarter in some sense,
but because some of us do study more intensively and come ready to
re-evaluate our ideas when we encounter others. What Python does in the
situation discussed is pretty much what an assortment of languages include
many C-based ones do. If it happens that your background is limited, fine.
Many of us here have been exposed to the ideas in 5 or a dozen or literally
hundreds of languages and variants and are well aware that some languages
treat Booleans differently. But note we are posting on this forum so we
generally don't find it that objectionable the way Python has chosen.

We welcome well-intentioned discussions and the question is not at all
stupid. But our answers may not be being seen as reasonable and that can be
of some concern. The answer remains that the language was designed this way
and many are happy with the design. Interestingly, I wonder if anyone has
designed an alternate object type that can be used mostly in place of
Booleans but which imposes changes and restrictions so trying to add a
Boolean to an integer, or vice versa, results in an error. Python is
flexible enough to do that and perhaps there already is a module out there
...


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Dino
Sent: Thursday, January 26, 2023 9:26 AM
To: python-list@python.org
Subject: Re: RE: bool and int


Wow. That was quite a message and an interesting read. Tempted to go deep
and say what I agree and what I disagree with, but there are two
issues: 1) time 2) I will soon be at a disadvantage discussing with people
(you or others) who know more than me (which doesn't make them right
necessarily, but certainly they'll have the upper-hand in a discussion).

Personally, in the first part of my career I got into the habit of learning
things fast, sometimes superficially I confess, and then get stuff done
hopefully within time and budget. Not the recommended approach if you need
to build software for a nuclear plant. An OK approach (within reason) if you
build websites or custom solutions for this or that organization and the
budget is what it is. After all, technology moves sooo fast, and what we
learn in detail today is bound to be old and possibly useless 5 years down
the road.

Also, I argue that there is value in having familiarity with lots of
different technologies (front-end and back-end) and knowing (or at lease,
having a sense) of how they can all be made play together with an
appreciation of the different challenges and benefits that each domain
offers.

Anyway, everything is equivalent to a Turing machine and IA will screw
everyone, including programmers, eventually.

Thanks again and have a great day

Dino

On 1/25/2023 9:14 PM, avi.e.gross@gmail.com wrote:
> Dino,
>
> There is no such things as a "principle of least surprise" or if you
> insist there is, I can nominate many more such "rules" such as "the
> principle of get out of my way and let me do what I want!"
>
> Computer languages with too many rules are sometimes next to unusable
> in practical situations.
>
> I am neither defending or attacking choices Python or other languages
> have made. I merely observe and agree to use languages carefully and
> as documented.
>
--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On 26/01/23 6:10 am, Chris Angelico wrote:
> 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 :)

Murphy's Law for Unix: If something can go wrong, it will go
wrong 255 times out of 256.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
avi.e.gross@gmail.com wrote:
...
> Interestingly, I wonder if anyone has
> designed an alternate object type that can be used mostly in place of
> Booleans but which imposes changes and restrictions so trying to add a
> Boolean to an integer, or vice versa, results in an error. Python is
> flexible enough to do that and perhaps there already is a module out there

Not exactly what you describe, but I did once write a subclass of int
for use in an SNMP interface, where true is represented as 1 and false
as 2. I don't recall the exact details offhand, but it involved
overriding __bool__ so that a value of 1 returned True and anything else
False. The way it was used should have ensured that it only ever had
the value 1 or 2, but doing it this way round (rather than e.g. 2 being
False and anything else True) meant that if it somehow got the value 0,
that would also be treated as False. I think it also overrode __init__
(or perhaps __new__) to covert a bool True or False to 1 or 2 (rather
than 1 or 0) for its own value, so it could be initialised from either
an int or a bool and correctly converted in either direction via int()
or bool().

So Python is even flexible enough to be made to deal with insane
situations where False is 2!

--
Mark.
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On Sat, 28 Jan 2023 at 11:45, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>
> On 26/01/23 6:10 am, Chris Angelico wrote:
> > 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 :)
>
> Murphy's Law for Unix: If something can go wrong, it will go
> wrong 255 times out of 256.
>

Murphy's Law for people working with small integers: "255 out of 256"
will, just when you least expect it, change into "255 out of 0".

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: RE: RE: bool and int [ In reply to ]
you have your reasons, and I was tempted to stop there, but... I have to
pick this...

On 1/26/2023 10:09 PM, avi.e.gross@gmail.com wrote:
> You can often borrow
> ideas and code from an online search and hopefully cobble "a" solution
> together that works well enough. Of course it may suddenly fall apart.

also carefully designed systems that are the work of experts may
suddenly fall apart.

Thank you for all the time you have used to address the points I raised.
It was interesting reading.

Dino

--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On 2023-01-27, Mark Bourne <nntp.mbourne@spamgourmet.com> wrote:

> So Python is even flexible enough to be made to deal with insane
> situations where False is 2!

IIRC, in VMS DCL even numbers were false and odd numbers were true.

In Unix shells, a return code of 0 is true and non-0 is false.

Though that's not really the same environment that Python lives in...


--
Grant
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On Fri, 27 Jan 2023 21:35:11 -0800 (PST), Grant Edwards wrote:

> In Unix shells, a return code of 0 is true and non-0 is false.

That carries over to some C functions like strcmp() although it's more
complex. strcmp() returns the value of subtracting the nth character of
string b from string a if the value is not 0. For matching strings, the
result is 0 for all character positions.

This plays nicely with sorting functions but naive programmers assume it's
a boolean and strcmp("foo", "foo") should return 1 or true when the
strings match.

Returning 0 for success gives you much more latitude in return values.
--
https://mail.python.org/mailman/listinfo/python-list
Re: bool and int [ In reply to ]
On Sun, 29 Jan 2023 at 11:27, rbowman <bowman@montana.com> wrote:
>
> On Fri, 27 Jan 2023 21:35:11 -0800 (PST), Grant Edwards wrote:
>
> > In Unix shells, a return code of 0 is true and non-0 is false.
>
> That carries over to some C functions like strcmp() although it's more
> complex. strcmp() returns the value of subtracting the nth character of
> string b from string a if the value is not 0. For matching strings, the
> result is 0 for all character positions.
>
> This plays nicely with sorting functions but naive programmers assume it's
> a boolean and strcmp("foo", "foo") should return 1 or true when the
> strings match.
>
> Returning 0 for success gives you much more latitude in return values.

That's not really about booleans, it's more like "imagine subtracting
one string from another". You can compare two integers by subtracting
one from another; you'll get a number that's less than zero, zero, or
greater than zero, just like with strcmp. And yes, that plays
perfectly with sorting functions. So when you want to compare strings,
what do you do? You make something that subtracts one string from
another.

It's "String Compare", not "Are Strings Equal", so it doesn't return a
boolean. Zero for equal makes very good sense, even though a "strings
equal" function would return zero for non-equal.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list

1 2  View All