On Sat, Feb 23, 2013 at 10:38 AM, <piterrr.dolin...@gmail.com> wrote:
> I think this obvious shortcomming is the main reason that, for example, when
> x holds the value of 5, x is considered to be "true". You see, I have to
> maintain Python files (ubuntu server scripts) which are 2000 lines long, all
> sequential code, no functions. While the person who wrote them should be shot
> :), the fact that there is inherent ambiguity with value, none, null 0, you
> name it, in conditional statements is not helping me understand the code, and
> this adds to my frustration.
When you want to clearly ask if something is the specific value True,
you can do that thus:
if x is True:
That's the canonical ("pythonic") way to explicitly check for a
boolean value, in the same way that PHP scripts test
strpos(...)===FALSE.
> Btw, there are still languages with no boolean type today, MySQL for one.
> This creates big efficiency problems when fetching data from the database
> into a C# program - what should be a bool is fetched as an 8-byte integer!
> But that's a different story. I shut up now.
It's really not that big a deal to have or not have an explicit
boolean type. Ultimately, the CPU is going to work with integers,
booleans, strings, and so on, in the same way, and that most likely
will be an integer of at least 4 bytes in size - the "machine word"
for your architecture. Asking for anything smaller comes with a
performance hit. So it's easier to store and manage booleans as 4-byte
or 8-byte integers containing either 1 or 0, than to have some kind of
"bit" type - unless we're talking about a *set* of booleans, which is
sometimes implemented as bitflags.
Really, there are worse things in the world. Don't get het up about
boolean types. :)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
