Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #38417 > unrolled thread

Re: Implicit conversion to boolean in if and while statements

Started byRick Johnson <rantingrickjohnson@gmail.com>
First post2013-02-07 22:16 -0800
Last post2013-02-07 22:16 -0800
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Implicit conversion to boolean in if and while statements Rick Johnson <rantingrickjohnson@gmail.com> - 2013-02-07 22:16 -0800

#38417 — Re: Implicit conversion to boolean in if and while statements

FromRick Johnson <rantingrickjohnson@gmail.com>
Date2013-02-07 22:16 -0800
SubjectRe: Implicit conversion to boolean in if and while statements
Message-ID<mailman.1482.1360304697.2939.python-list@python.org>
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 comprehension of your words. He is so accustomed to "guessing" that it has become second nature 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 collections should 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.

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web