Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Implicit conversion to boolean in if and while statements

Reply
Thread Tools

Implicit conversion to boolean in if and while statements

 
 
Laszlo Nagy
Guest
Posts: n/a
 
      07-17-2012
On 2012-07-17 10:23, Andrew Berg wrote:
> I don't want that, but I am suggesting that it would be consistent with
> the idea of "something or nothing".

Don't confuse names and objects. You can only test the truth value of
objects. If you don't have a name in a namespace, then it means you
don't have a tool to have a reference to anything (including the False
object).

Using the same logic you could also say that not giving any condition to
the "if" statement should be evaluated as False:

if:
print "This never gets executed"

But it makes no sense.
 
Reply With Quote
 
 
 
 
Laszlo Nagy
Guest
Posts: n/a
 
      07-17-2012

> Not really. It doesn't quack like anything.

Actually, there is no "it". So we cannot talk about how it quacks.

 
Reply With Quote
 
 
 
 
Terry Reedy
Guest
Posts: n/a
 
      07-17-2012
On 7/17/2012 4:23 AM, Andrew Berg wrote:
> On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
>> The default behaviour is that every object is something, hence true-like,
>> unless explicitly coded to be treated as false-like. Since both loggers
>> and functions are objects, they are true-like unless the default is
>> overridden.

> I am aware of the default behavior, but the reason for it still eludes me.


Ultimately, because Guido's intuition said that the current behavior is
the best. I happen to agree on this one.

Quoting from elsewhere:
> If it truly is about something vs. nothing, why is a NameError (or
> AttributeError) raised when testing with an undefined variable?



Python does not have 'undefined variable' objects in the way that some
other languages do. There is nothing to test 'with'. 'if
undefined_name:' raises NameError because all uses of undefined_names
other that assignments do. The actually execution order is expression
first, then if. You can explicitly test "'some_name' in namespace" or
"hasattr(obj, 'somename') by turning the possibly undefined name into a
string object.

--
Terry Jan Reedy



 
Reply With Quote
 
alex23
Guest
Posts: n/a
 
      07-18-2012
On Jul 17, 6:23*pm, Andrew Berg <(E-Mail Removed)> wrote:
> On 7/17/2012 2:08 AM, Steven D'Aprano wrote:
> > The default behaviour is that every object is something, hence true-like,
> > unless explicitly coded to be treated as false-like. Since both loggers
> > and functions are objects, they are true-like unless the default is
> > overridden.

>
> I am aware of the default behavior, but the reason for it still eludes me..


Because it makes it simple to distinguish between having an object and
not having one without having to explicitly test for it each time.

db = connect("my:db") # or None if the connection failed
if db:
<do something>

I find that usage to be incredibly intuitive.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-08-2013
On Monday, July 16, 2012 7:43:47 PM UTC-5, Steven D'Aprano wrote:
>
> [...]
>
> If I insist on making a single object do duty for both the jar and the
> jellybean count, then I need a "null jar object", and I probably end up
> with something like this:
>
> Jar(number_of_beans=None) => null jar object with jar.jellybeans = 0
> Jar(number_of_beans=0) => normal jar object with jar.jellybeans = 0
> Jar(number_of_beans=42) => normal jar object with jar.jellybeans = 42
>
> and then my code becomes even more complicated and less understandable,
> but hey, it's *my* code and I can do whatever damn-fool thing I like!


Indeed, but why would you create a jellybean jar and never put any jelly beans into the jar? If you are doing so because you want to loop over a number of objects and never get a NameError than you need to study up on a few language features you may be unaware of:

1. block: try/except
2. statement: if
3. function: hasattr(obj, name)

Creating /any/ object that is never utilized is code smell; I don't care how extravagant your explanations are either -- and boy did you go to some great efforts to explain this line of argument. I'm impressed!
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-08-2013
On Monday, July 16, 2012 8:45:51 PM UTC-5, rusi wrote:
> On Jul 15, 9:50 pm, Rick Johnson <(E-Mail Removed)> wrote:


> > I think this issue is not so much a "bool test" vs "type
> > test", but more an ambiguous syntax issue.
> >

>
> If you know some English, its clear that if and while
> create bool contexts.


Wrong. "if and "while" do not /create/ anything. On a syntactical level they merely /suggest/ to the reader that the following statement is expected to be a boolean value. It is the /statement/ itself that creates the booleanvalue, not the keywords!

Observe:

0 == 0 -> True
isinstance("5", int) -> False

You see, "if" and "while" don't create anything, in reality they merely execute a block of code depending on the value of the statement that follows the keyword. "if" and "while" are only *logical switches* and nothing more. You could write a simple quasi-example of "if" as a function like this:

def if_(value):
if not value:
return
# do_something_here


Those previous statements where /explicit/, and as such need no bool() function to resolve their Boolean values, however, consider the following /implicit/ conversions to Boolean:

[] -> False
[1] -> True
"" -> False
"1" -> True
0 -> False
1 -> True
2 -> True
etc...

It is my strong opinion that these types of implicit conversions are evil obfuscations of the truth. If we want to convert an object to a Boolean, then use the bool() function on that object:

bool([]) -> False
bool([1]) -> True
etc...

Heck! Why even have a damn bool function if you're never going to use it?

> [If you know English but have not
> studied logic the 'if/while' make sense whereas 'bool' is
> gobbledygook]


And which Univeristy would you recommend for studying the intricacies of "gobbledygook"?

 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      02-08-2013
On Fri, Feb 8, 2013 at 4:53 PM, Rick Johnson
<(E-Mail Removed)> wrote:
> And which Univeristy would you recommend for studying the intricacies of "gobbledygook"?


Dunno, where'd you get your degree in logic?

*dives for cover*

ChrisA
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-08-2013
On Monday, July 16, 2012 11:18:28 PM UTC-5, Devin Jeanpierre wrote:
> On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano wrote:
> > On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
> >
> >> For example, instead of "if stack:" or "if bool(stack):", we could use
> >> "if stack.isempty():". This line tells us explicitly that stack is a
> >> container.

> >
> > isempty is not a container method.

>
> Your entire reply is predicated on this idea that I was talking about
> writing classes with this extra "isempty" method.


Steven's adherence to this implicit conversion is warping his comprehensionof your words. He is so accustomed to "guessing" that it has become secondnature for him.

> No. I was talking about having "isempty" be part of the collection
> interface, and eliminating polymorphic bool conversion.


Which i believe is a great idea!

GvR has always been reluctant to incorporate full OOP machinery for some reason. I am not suggesting that Python be 100% OOP, HELL NO! But collectionsshould have had an "isempty" method from the beginning. But the same argument could be made against len, any, all, etc...

But now we are opening a whole bag of cats. What about hasattr, getattr, setattr, type, dir, id, isinstance, issubclass, and many more that could be inherited directly from object; and they should be!

On the flip side i do believe int, float, str, tuple, list, dict... should remain as built-ins, and the obvious: help, input, globals, locals, vars, print, etc...

Python has too many built-ins. I think we need a PyWart on this subject.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-08-2013
On Monday, July 16, 2012 11:18:28 PM UTC-5, Devin Jeanpierre wrote:
> On Mon, Jul 16, 2012 at 12:03 AM, Steven D'Aprano wrote:
> > On Sun, 15 Jul 2012 22:15:13 -0400, Devin Jeanpierre wrote:
> >
> >> For example, instead of "if stack:" or "if bool(stack):", we could use
> >> "if stack.isempty():". This line tells us explicitly that stack is a
> >> container.

> >
> > isempty is not a container method.

>
> Your entire reply is predicated on this idea that I was talking about
> writing classes with this extra "isempty" method.


Steven's adherence to this implicit conversion is warping his comprehensionof your words. He is so accustomed to "guessing" that it has become secondnature for him.

> No. I was talking about having "isempty" be part of the collection
> interface, and eliminating polymorphic bool conversion.


Which i believe is a great idea!

GvR has always been reluctant to incorporate full OOP machinery for some reason. I am not suggesting that Python be 100% OOP, HELL NO! But collectionsshould have had an "isempty" method from the beginning. But the same argument could be made against len, any, all, etc...

But now we are opening a whole bag of cats. What about hasattr, getattr, setattr, type, dir, id, isinstance, issubclass, and many more that could be inherited directly from object; and they should be!

On the flip side i do believe int, float, str, tuple, list, dict... should remain as built-ins, and the obvious: help, input, globals, locals, vars, print, etc...

Python has too many built-ins. I think we need a PyWart on this subject.
 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      02-08-2013
On Tuesday, July 17, 2012 8:35:09 PM UTC-5, alex23 wrote:
> On Jul 17, 6:23*pm, Andrew Berg <(E-Mail Removed)> wrote:
>
> > On 7/17/2012 2:08 AM, Steven D'Aprano wrote:

>
> > > The default behaviour is that every object is something, hence true-like,

>
> > > unless explicitly coded to be treated as false-like. Since both loggers

>
> > > and functions are objects, they are true-like unless the default is

>
> > > overridden.

>
> >

>
> > I am aware of the default behavior, but the reason for it still eludes me.

>
>
>
> Because it makes it simple to distinguish between having an object and
>
> not having one without having to explicitly test for it each time.
>
>
>
> db = connect("my:db") # or None if the connection failed
>
> if db:
>
> <do something>
>
>
>
> I find that usage to be incredibly intuitive.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Implicit conversion to boolean in if and while statements Stefan Behnel Python 0 07-15-2012 09:17 AM
Re: Implicit conversion to boolean in if and while statements Chris Angelico Python 0 07-15-2012 08:47 AM
Subtle difference between boolean value and boolean comparison? Metre Meter Javascript 7 08-06-2010 08:40 PM
if statements and case statements questions John Crichton Ruby 6 07-12-2010 06:17 PM
difference between 'boolean' and 'java.lang.Boolean' J Leonard Java 4 01-19-2008 02:56 AM



Advertisments