Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
$ python Python 3.8.10 (default, Mar 15 2022, 12:22:08)
[GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license"
for more information.
Trueb = True isinstance(b,bool)
Trueisinstance(b,int)
WTF!
Trueb = True
isinstance(b, bool)
Trueisinstance(b, int)
11c = b + 10
print(c)
10b = False
c = b + 10
print(c)
|2True + True
|0False * 5
|2isinstance(b,int)
True + True
|0False * 5
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
For backwards compatibility, bool was made a subclass of int.
C# is pickier, which I guess is a good thing.
https://peps.python.org/pep-0285/
From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of rbowman <bowman@montana.com>
Date: Tuesday, January 24, 2023 at 3:01 PM
To: python-list@python.org <python-list@python.org>
Subject: Re: bool and int
bool is a subtype of integer. I never dug that deep into Python's guts but
I assume it goes back to boolean being an afterthought in C. Some people fancy it up with #defines but I always use int. 0 is false, anything else
is true.
C# is pickier, which I guess is a good thing.
On Wed, 25 Jan 2023 at 08:22, MRAB <python@mrabarnett.plus.com> wrote:
For backwards compatibility, bool was made a subclass of int.
Plus, it's really REALLY handy in quite a lot of situations.
C# is pickier, which I guess is a good thing.
Nope, not a good thing. Actually a highly frustrating thing on those occasions when I have to write C# code.
On 2023-01-25 at 08:58:06 +1100,
Chris Angelico <rosuav@gmail.com> wrote:
On Wed, 25 Jan 2023 at 08:22, MRAB <python@mrabarnett.plus.com> wrote:
For backwards compatibility, bool was made a subclass of int.
Plus, it's really REALLY handy in quite a lot of situations.
C# is pickier, which I guess is a good thing.
Nope, not a good thing. Actually a highly frustrating thing on those occasions when I have to write C# code.
The usual complaint is that some people write FORTRAN no matter what
language they're actually using. Are you writing Python in C#? ;-)
Will all of you please stop sending me emails
Sent from my iPhone
Will all of you please stop sending me emails
On Jan 24, 2023, at 2:59 PM, rbowman <bowman@montana.com> wrote:
On Mon, 23 Jan 2023 23:22:00 -0500, Dino wrote:
$ python Python 3.8.10 (default, Mar 15 2022, 12:22:08)
[GCC 9.4.0] on linux Type "help", "copyright", "credits" or "license"
for more information.
Trueb = True isinstance(b,bool)
Trueisinstance(b,int)
WTF!
Trueb = True
isinstance(b, bool)
Trueisinstance(b, int)
11c = b + 10
print(c)
10b = False
c = b + 10
print(c)
bool is a subtype of integer. I never dug that deep into Python's guts but
I assume it goes back to boolean being an afterthought in C. Some people fancy it up with #defines but I always use int. 0 is false, anything else is true.
C# is pickier, which I guess is a good thing.
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, 25 Jan 2023 at 08:22, MRAB <python@mrabarnett.plus.com> wrote:
For backwards compatibility, bool was made a subclass of int.
Plus, it's really REALLY handy in quite a lot of situations.
C# is pickier, which I guess is a good thing.
Nope, not a good thing. Actually a highly frustrating thing on those occasions when I have to write C# code.
Python has a different philosophy than some other languages with strong typing. In some of those, you would not be allowed to add or multiply at random but would need to convert parts of your calculation to all be the same, such as a 32-bit integer. You could still do things like I mention above but only after consciously mapping your Boolean to an actual zero or one of the kind wanted.
I worry a tad more about the other direction where something like an integer containing a number like 12 is used in a context where it gets downgraded to a True/False and later may inadvertently be used as a "1" as the conversion is not anticipated. There is data loss there more than in the case of a Boolean becoming a 1.
Will all of you please stop sending me emails
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:
On 2023-01-25 at 12:14:50 +1100,
Chris Angelico <rosuav@gmail.com> wrote:
On Wed, 25 Jan 2023 at 10:32, <2QdxY4RzWzUUiLuE@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.
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.
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.
(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.
No.
No!!!"""
On Wed, 25 Jan 2023 at 10:32, <2QdxY4RzWzUUiLuE@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:
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:
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.
(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.
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.
On Wed, 25 Jan 2023 at 22:55, <2QdxY4RzWzUUiLuE@potatochowder.com> wrote:
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.
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.
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).
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'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).
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."
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.
Will all of you please stop sending me emails
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
On 1/23/2023 11:22 PM, Dino wrote:
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
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!
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
On 1/23/2023 11:22 PM, Dino wrote:
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
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!
On Wed, 25 Jan 2023 at 12:43, <avi.e.gross@gmail.com> wrote:
Python has a different philosophy than some other languages with strong typing. In some of those, you would not be allowed to add or multiply at random but would need to convert parts of your calculation to all be the same, such as a 32-bit integer. You could still do things like I mention above but only after consciously mapping your Boolean to an actual zero or one of the kind wanted.
Python is strongly dynamically typed. You may be thinking of "static
typing" rather than "strong typing" here,
On Wed, 25 Jan 2023 at 12:43, <avi.e.gross@gmail.com> wrote:
Python has a different philosophy than some other languages with
strong typing. In some of those, you would not be allowed to add or multiply at random but would need to convert parts of your
calculation to all be the same, such as a 32-bit integer. You could
still do things like I mention above but only after consciously
mapping your Boolean to an actual zero or one of the kind wanted.
Python is strongly dynamically typed. You may be thinking of "static
typing" rather than "strong typing" here,
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.
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.
I can’t help but wonder if there exists some Java forum /mailing list going on about how horrible Python is.
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.
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.
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
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!
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.
On Thu, 26 Jan 2023 at 08:19, Dino <dino@no.spam.ar> wrote:
On 1/23/2023 11:22 PM, Dino wrote:
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
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!
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.
Falsetype(True) == type(1)
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.
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 :)
$ python
Python 3.8.10 (default, Mar 15 2022, 12:22:08)
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
Trueb = True
isinstance(b,bool)
Trueisinstance(b,int)
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
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.
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.
So Python is even flexible enough to be made to deal with insane
situations where False is 2!
In Unix shells, a return code of 0 is true and non-0 is false.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 35:21:52 |
| Calls: | 10,392 |
| Calls today: | 3 |
| Files: | 14,064 |
| Messages: | 6,417,146 |