On Wed, Jun 5, 2013 at 4:11 PM, Russ P. <russ.paie...@gmail.com> wrote:
> On Tuesday, June 4, 2013 8:44:11 AM UTC-7, Rick Johnson wrote:
>
>> Yes, but the problem is not "my approach", rather the lack
>>
>> of proper language design (my apologizes to the "anointed
>>
>> one". ;-)
>
> If you don't like implicit conversion to Boolean, then maybe you should be
> using another language -- and I mean that in a constructive sense. I'm not
> particularly fond of it either, but I switched from Python to another
> language a while back. The issue is not a lack of "proper language design"
> but rather a language design philosophy that values conciseness and
> simplicity over explicitness and rigor.
(Out of curiosity, which language? Feel free to not answer, or to
answer off-list, as that's probably not constructive to the thread.)
I cannot name a single modern programming language that does NOT have
some kind of implicit boolification. The only such language I know of
is REXX, which has a single data type for everything, but insists on
the exact strings "1" and "0" for True and False, anything else is an
error. Every other language has some definition of "these things are
true, these are false"; for instance:
* C-family languages treat all nonzero integers as true
* Shells treat 0 as "success" and nonzero as "error", and therefore as
"true" and "false" respectively (yes, this IS an inversion)
* Pike allows any variable to contain the integer 0, regardless of its
declared type, and thus is a sort of "null" value which is false; all
strings, arrays, mappings, etc are true
* Python treats an empty "thing" as false and a nonempty one as true
SQL is like REXX in that it's fairly strict; a condition must be a
boolean (example from PostgreSQL):
rosuav=> select 1+2 where 1;
ERROR: argument of WHERE must be type boolean, not type integer
LINE 1: select 1+2 where 1;
^
But an explicit conversion is permitted:
rosuav=> select 1+2 where cast (5 as boolean);
?column?
----------
3
(1 row)
> It's all loosey goosey -- which is fine for many applications but certainly
> not for critical ones.
The looseness doesn't preclude critical applications. It's all a
question of what you're testing. Does your code care that this be a
list, and not something else? Then test! You have that option. What
happens if it isn't a list, and something is done that bombs with an
exception? Maybe that's not a problem.
Critical applications can often be built in layers. For instance, a
network server might listen for multiple socket connections, and for
each connection, process multiple requests. You would want to catch
exceptions at the two boundaries there; if a request handler crashes,
the connection should not be dropped, and if a connection handler
crashes, the server should keep running. With some basic defenses like
that, your code need no longer concern itself with trivialities - if
something goes wrong, there'll be an exception in the log. (BTW, this
is one of the places where a bare or very wide except clause is
appropriate. Log and move on.)
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
