What is the rationale for considering all instances true of a user- defined type? Is it strictly a practical stipulation, or is there something conceptually true about objects?
''' object.__bool__(self) If a class defines neither __len__() nor __bool__(), all its instances are considered true. '''
This makes it so all objects except False, None, 0, and empty containers are true by default. I am not convinced that 'if <a generic object>' should have any meaning; it should probably throw an exception. Is it part of Python's look and feel or its mentality? Is it part of the Zen? Certainly other ideal types can't be cast from generic objects, so why booleans? Is it an ineffable component of the author's vision for the language? I think that giving arbitrary syntactic constructs meaning is just space-filler. It's worse than syntactic sugar, it's semantic sugar. Why not assign meanings willy- nilly to other random juxtapositions of tokens?
Aaron Brady wrote: > What is the rationale for considering all instances true of a user- > defined type?
User-defined objects (or type) can override .__len__() [usually container types] or .__nonzero__() to make bool() returns False.
> Is it strictly a practical stipulation, or is there > something conceptually true about objects?
Objects are true unless they define themself as false. The practical implication is we can do this:
def foo(args = None): if args: ...
In python all objects are true except: None, False, 0/0L/0.0/0j, empty sequence or container, and on objects that defines .__len__() or .__nonzero__() that returns 0 or False.
> ''' > object.__bool__(self) > If a class defines neither __len__() nor __bool__(), all its instances > are considered true. > '''
> This makes it so all objects except False, None, 0, and empty > containers are true by default. I am not convinced that 'if <a > generic object>' should have any meaning; it should probably throw an > exception. Is it part of Python's look and feel or its mentality? Is > it part of the Zen? Certainly other ideal types can't be cast from > generic objects, so why booleans? Is it an ineffable component of the > author's vision for the language? I think that giving arbitrary > syntactic constructs meaning is just space-filler. It's worse than > syntactic sugar, it's semantic sugar. Why not assign meanings willy- > nilly to other random juxtapositions of tokens?
It's part of the design decision. In almost all cases (in any language), a so-called "Design Decision" is rather random and prone to subjective judgment, just as the decision to make bool(int) returns False only on 0, -1, or for all negative values; whether to make bool(100) and exception or True; or round() rounds down or up or even-odd; or the use of brackets vs. indentation; or whether to treat empty list as True or False.
On Mon, Apr 27, 2009 at 11:11 PM, Aaron Brady <castiro...@gmail.com> wrote: > What is the rationale for considering all instances true of a user- > defined type? Is it strictly a practical stipulation, or is there > something conceptually true about objects?
> ''' > object.__bool__(self) > If a class defines neither __len__() nor __bool__(), all its instances > are considered true. > '''
> This makes it so all objects except False, None, 0, and empty > containers are true by default. I am not convinced that 'if <a > generic object>' should have any meaning; it should probably throw an > exception. Is it part of Python's look and feel or its mentality? Is > it part of the Zen? Certainly other ideal types can't be cast from > generic objects, so why booleans? Is it an ineffable component of the > author's vision for the language? I think that giving arbitrary > syntactic constructs meaning is just space-filler. It's worse than > syntactic sugar, it's semantic sugar. Why not assign meanings willy- > nilly to other random juxtapositions of tokens?
I believe the justification is that in the case of objects with otherwise undefined truth, it effectively serves as a test for non-None-ness, which makes some sense and is apparently more useful in practice than throwing an exception. It was obviously a design decision made by the PSU, probably for "practicality over purity" reasons; indeed, they could reasonably have chose to make it throw an exception in such cases, but the current behavior is also reasonable and justifiable. For comparison, some other languages use a similar definition of truth ("if you can't show it's false, then it's true"), such as Lisp/Scheme and Ruby ("if it's not equal to #f/false or nil, then it's true"). Admittedly, it's not a direct comparison since Python has fancier semantics, but it's somewhat similar.
> Aaron Brady wrote: > > What is the rationale for considering all instances true of a user- > > defined type?
> User-defined objects (or type) can override .__len__() [usually > container types] or .__nonzero__() to make bool() returns False.
> > Is it strictly a practical stipulation, or is there > > something conceptually true about objects?
> Objects are true unless they define themself as false. The practical > implication is we can do this:
> def foo(args = None): > if args: > ...
> In python all objects are true except: None, False, 0/0L/0.0/0j, empty > sequence or container, and on objects that defines .__len__() or > .__nonzero__() that returns 0 or False.
> > ''' > > object.__bool__(self) > > If a class defines neither __len__() nor __bool__(), all its instances > > are considered true. > > '''
> > This makes it so all objects except False, None, 0, and empty > > containers are true by default. I am not convinced that 'if <a > > generic object>' should have any meaning; it should probably throw an > > exception. Is it part of Python's look and feel or its mentality? Is > > it part of the Zen? Certainly other ideal types can't be cast from > > generic objects, so why booleans? Is it an ineffable component of the > > author's vision for the language? I think that giving arbitrary > > syntactic constructs meaning is just space-filler. It's worse than > > syntactic sugar, it's semantic sugar. Why not assign meanings willy- > > nilly to other random juxtapositions of tokens?
> It's part of the design decision. In almost all cases (in any language), > a so-called "Design Decision" is rather random and prone to subjective > judgment, just as the decision to make bool(int) returns False only on > 0, -1, or for all negative values; whether to make bool(100) and > exception or True; or round() rounds down or up or even-odd; or the use > of brackets vs. indentation; or whether to treat empty list as True or > False.
Whether it's a good feature and whether it's a popular feature are two different things. (It's not always clear that the former is even real anyway.)
I'm actually not sure that my question was /entirely/ scientifically motivated. Perhaps I'm expressing admiration (or maybe envy). Maybe I want to design a popular language too.
If I was really being scientific, I would have been wondering, what is the balance of pros and cons of the decision? pros - cons = ? Is that an objective expression? Are there only measurable quantities in both operands? If it's a close call, I might not agree, or might not have followed the same experimental method.
Trivially the answer is, 'the decision maker found sum( pros ) > sum ( cons )'. Many arts and disciplines do guesswork to a degree in evaluating their 'sum( pros )', so perhaps I should expect a degree of variation in what the experts all say that quantity is.
On a more idealist's level, perhaps I am asking the outside world what /my/ evaluation of 'sum( pros )' is. What's yours?
On Mon, 27 Apr 2009 23:11:11 -0700, Aaron Brady wrote: > What is the rationale for considering all instances true of a user- > defined type? Is it strictly a practical stipulation, or is there > something conceptually true about objects?
Seven years ago, in an attempt to convince Guido *not* to include booleans in Python, Laura Creighton wrote a long, detailed post explaining her opposition.
At the heart of her argument is the observation that Python didn't need booleans, at least not the ints-in-fancy-hats booleans that we've ended up with, because Python already made a far more useful and fundamental distinction: between Something and Nothing.
All objects are either Something or Nothing. The instances of some classes are always Something, just as the instances of some classes are always Nothing. By default, instances are Something, unless __nonzero__ returns False, or __len__ returns 0, then they are Nothing.
In a boolean (or truth) context, Something and Nothing behave like True and False in languages with real booleans:
if obj: print "I am Something" else: print "I am Nothing"
To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing 0, a singleton Nothing None, and so forth. It also has many corresponding Somethings.
All bool() does is convert Something or Nothing into a canonical form, the subclassed ints True and False.
I'm not sure whether Guido ever used the terms Something vs Nothing when describing Python's truth-testing model, but it is clearly there, at the heart of Python. Python didn't even get a boolean type until version 2.3.
fef4-4bf8-8054-16dc9b5c8...@d2g2000pra.googlegroups.com>, Aaron Brady wrote: > What is the rationale for considering all instances true of a user- > defined type?
It's a stupid idea, and there seem to be instances of users tripping over it here in comp.lang.python every week.
Lie Ryan wrote: > Aaron Brady wrote: >> What is the rationale for considering all instances true of a user- >> defined type?
> User-defined objects (or type) can override .__len__() [usually > container types] or .__nonzero__() to make bool() returns False.
>> Is it strictly a practical stipulation, or is there >> something conceptually true about objects?
> Objects are true unless they define themself as false. The practical > implication is we can do this:
> def foo(args = None): > if args: > ...
> In python all objects are true except: None, False, 0/0L/0.0/0j, empty > sequence or container, and on objects that defines .__len__() or > ..__nonzero__() that returns 0 or False.
>> ''' >> object.__bool__(self) >> If a class defines neither __len__() nor __bool__(), all its instances >> are considered true. >> '''
>> This makes it so all objects except False, None, 0, and empty >> containers are true by default. I am not convinced that 'if <a >> generic object>' should have any meaning; it should probably throw an >> exception. Is it part of Python's look and feel or its mentality? Is >> it part of the Zen? Certainly other ideal types can't be cast from >> generic objects, so why booleans? Is it an ineffable component of the >> author's vision for the language? I think that giving arbitrary >> syntactic constructs meaning is just space-filler. It's worse than >> syntactic sugar, it's semantic sugar. Why not assign meanings willy- >> nilly to other random juxtapositions of tokens?
> It's part of the design decision. In almost all cases (in any language), > a so-called "Design Decision" is rather random and prone to subjective > judgment, just as the decision to make bool(int) returns False only on > 0, -1, or for all negative values; whether to make bool(100) and > exception or True; or round() rounds down or up or even-odd; or the use > of brackets vs. indentation; or whether to treat empty list as True or > False.
I'm puzzled by the last sentence:
*** Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit (Intel)] on win32. ***
>>> What is the rationale for considering all instances true of a user- >>> defined type?
>> User-defined objects (or type) can override .__len__() [usually container >> types] or .__nonzero__() to make bool() returns False.
>>> Is it strictly a practical stipulation, or is there >>> something conceptually true about objects?
>> Objects are true unless they define themself as false. The practical >> implication is we can do this:
>> def foo(args = None): >> if args: >> ...
>> In python all objects are true except: None, False, 0/0L/0.0/0j, empty >> sequence or container, and on objects that defines .__len__() or >> ..__nonzero__() that returns 0 or False.
>>> ''' >>> object.__bool__(self) >>> If a class defines neither __len__() nor __bool__(), all its instances >>> are considered true. >>> '''
>>> This makes it so all objects except False, None, 0, and empty >>> containers are true by default. I am not convinced that 'if <a >>> generic object>' should have any meaning; it should probably throw an >>> exception. Is it part of Python's look and feel or its mentality? Is >>> it part of the Zen? Certainly other ideal types can't be cast from >>> generic objects, so why booleans? Is it an ineffable component of the >>> author's vision for the language? I think that giving arbitrary >>> syntactic constructs meaning is just space-filler. It's worse than >>> syntactic sugar, it's semantic sugar. Why not assign meanings willy- >>> nilly to other random juxtapositions of tokens?
>> It's part of the design decision. In almost all cases (in any language), a >> so-called "Design Decision" is rather random and prone to subjective >> judgment, just as the decision to make bool(int) returns False only on 0, >> -1, or for all negative values; whether to make bool(100) and exception or >> True; or round() rounds down or up or even-odd; or the use of brackets vs. >> indentation; or whether to treat empty list as True or False.
> I'm puzzled by the last sentence:
> *** Python 2.6.2 (r262:71605, Apr 14 2009, 22:40:02) [MSC v.1500 32 bit > (Intel)] on win32. ***
> Lie Ryan wrote: >> Aaron Brady wrote: >>> This makes it so all objects except False, None, 0, and empty >>> containers are true by default. I am not convinced that 'if <a >>> generic object>' should have any meaning; it should probably throw an >>> exception. Is it part of Python's look and feel or its mentality? Is >>> it part of the Zen? Certainly other ideal types can't be cast from >>> generic objects, so why booleans? Is it an ineffable component of the >>> author's vision for the language? I think that giving arbitrary >>> syntactic constructs meaning is just space-filler. It's worse than >>> syntactic sugar, it's semantic sugar. Why not assign meanings willy- >>> nilly to other random juxtapositions of tokens? >> It's part of the design decision. In almost all cases (in any >> language), a so-called "Design Decision" is rather random and prone to >> subjective judgment, just as the decision to make bool(int) returns >> False only on 0, -1, or for all negative values; whether to make >> bool(100) and exception or True; or round() rounds down or up or >> even-odd; or the use of brackets vs. indentation; or whether to treat >> empty list as True or False.
That's the "design decision". bool(-1) *might* have been False, and bool(-100) *might* raise an exception. They behave the way they do because of a conscious decision.
Steven D'Aprano wrote: > On Mon, 27 Apr 2009 23:11:11 -0700, Aaron Brady wrote: >... In a boolean (or truth) context, Something and Nothing behave like True
> and False in languages with real booleans:
> if obj: > print "I am Something" > else: > print "I am Nothing"
If you define the short-circuit boolean operators "and" and "or" as Python does, the idea of "most anything is True" menas you can have code that does: v = look('here') or look('there') or look('everywhere') or default
This is a nice idiom, and the "or default" can be used in lots of cases.
<ste...@REMOVE.THIS.cybersource.com.au> wrote: > On Mon, 27 Apr 2009 23:11:11 -0700, Aaron Brady wrote: > > What is the rationale for considering all instances true of a user- > > defined type? Is it strictly a practical stipulation, or is there > > something conceptually true about objects?
> Seven years ago, in an attempt to convince Guido *not* to include > booleans in Python, Laura Creighton wrote a long, detailed post > explaining her opposition.
> At the heart of her argument is the observation that Python didn't need > booleans, at least not the ints-in-fancy-hats booleans that we've ended > up with, because Python already made a far more useful and fundamental > distinction: between Something and Nothing.
> All objects are either Something or Nothing. The instances of some > classes are always Something, just as the instances of some classes are > always Nothing. By default, instances are Something, unless __nonzero__ > returns False, or __len__ returns 0, then they are Nothing.
> In a boolean (or truth) context, Something and Nothing behave like True > and False in languages with real booleans:
> if obj: > print "I am Something" > else: > print "I am Nothing"
> To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a > list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing > 0, a singleton Nothing None, and so forth.
The sound of that metaphor is rather pleasing ('sweet nothings'), but I'm not so sure that metaphors belong in computer science and programming. Nothing can't have many shapes. Having no onions is the same as having no carrots. If the different shapes of nothing don't compare equal to each other, which they don't, then they aren't all the same thing in different shapes.
Furthermore, it is awfully presumptuous to give objects a default 'nothing-ness' of 'something'. If anything, they should be nothing by default. Conversion to other primitives is very picky; why should Boolean be so tolerant?
> The sound of that metaphor is rather pleasing ('sweet nothings'), but > I'm not so sure that metaphors belong in computer science and > programming. Nothing can't have many shapes. Having no onions is the > same as having no carrots.
Not if you need onions but not carrots it isn't!
-- Rhodri James *-* Wildebeeste Herder to the Masses
On Tue, 28 Apr 2009 11:59:18 -0700, Aaron Brady wrote: >> To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a >> list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing >> 0, a singleton Nothing None, and so forth.
> The sound of that metaphor is rather pleasing ('sweet nothings'), but > I'm not so sure that metaphors belong in computer science and > programming.
Programming models the world, it isn't the world. Every model is a metaphor. You can't get away from metaphors in programming, you can only hide them and pretend they aren't there.
> Nothing can't have many shapes.
In computing, you can't have a literal "nothing", because EVERYTHING needs to be stored as a pattern of bits. In practice, for most high-level languages, those bits are interpreted as a type as well as a value, so the same bit pattern can mean different things according to what type it is expected to be. Alternatively, the same information can be represented in different bit patterns depending on how you interpret those bit patterns.
So in the context of computer programming, of course you can have nothing with many "shapes": you have the number 0 represented as a single byte, a 16-bit integer, a 32-bit integer, a long-int or BigNum, a pointer with address 0, fixed point decimals of various sizes, Binary Coded Decimal, a rational, a single float 0.0, a double float 0.0, a string of "tally marks" without any tally, and so on, all of them in big-endian and little- endian formats.
> Having no onions is the same as having no carrots.
"If you have one onion and I take it away, how many onions do you have left?"
If you answered "no carrots", I'd consider that a bizarre and unhelpful answer, and wonder what you possibly thought carrots had to do with my question.
"Nothing" is not an absolute. "There is no wind" is not the same thing as "there is no money left in my bank account".
> If the different shapes of nothing don't > compare equal to each other, which they don't, then they aren't all the > same thing in different shapes.
Who said they were the same thing?
> Furthermore, it is awfully presumptuous to give objects a default > 'nothing-ness' of 'something'. If anything, they should be nothing by > default.
That's a stupid idea.
There are 4,294,967,296 integers that can be represented in 32 bits. Only one of them represents zero.
The number of possible strings is unlimited (except by physical limitations, such as the amount of memory available, or the size of the universe). Again, only one of them is the empty string.
Likewise for sets, lists, tuples, dicts, binary trees, queues, and just about every data structure you care to name: at most one such instance is empty, out of a potential infinite number of instances.
Most data represents *useful information* ("Something"), not the absence of information ("Nothing"). Why on earth would you want to reverse that presumption?
> Conversion to other primitives is very picky; why should > Boolean be so tolerant?
Because it is useful and meaningful to ask whether an arbitrary object represents something or nothing, but it's not useful or meaningful to ask what integer is equivalent to an arbitrary object.
> In message <54cb7f8a- > fef4-4bf8-8054-16dc9b5c8...@d2g2000pra.googlegroups.com>, Aaron Brady wrote:
>> What is the rationale for considering all instances true of a user- >> defined type?
> It's a stupid idea,
Nope, it's a very sensible default (given you can redefine the 'nothingness' value of your types instances), specially when the language doesn't have a proper boolean type (which was the case for Python until 2.2 or 2.3, can't remember exactly).
> and there seem to be instances of users tripping over it > here in comp.lang.python every week.
Which is why some users opposed to the introduction of a boolean type in Python by the time. Please read Steven D'aprano's post upper in this thread, and follow the provided link. Laura Creighton was alas spot on: introducing a boolean type only resulted in confusion.
In article <340175e7-b349-4ca2-bf66-fa9113253...@v23g2000pro.googlegroups.com>, Aaron Brady <castiro...@gmail.com> wrote:
>The sound of that metaphor is rather pleasing ('sweet nothings'), but >I'm not so sure that metaphors belong in computer science and >programming.
Well, you won't be a good programmer if you can't wrap your head around metaphor. All programming is about translating human thought into human language -- albeit a very special language with (mostly) precise rules. Repeat: programming languages are human languages. -- Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair
Bruno Desthuilliers wrote: > Lawrence D'Oliveiro a crit : >>> What is the rationale for considering all instances true of a user- >>> defined type?
>> It's a stupid idea,
> Nope, it's a very sensible default (given you can redefine the > 'nothingness' value of your types instances), specially when the > language doesn't have a proper boolean type (which was the case for > Python until 2.2 or 2.3, can't remember exactly).
Man, you've given a serious answer to a sarcastic reply to an OP who has been -- for years -- second in trolliness only to Xah Lee.
Either that, or I have to replace my humor detector.
<ste...@REMOVE.THIS.cybersource.com.au> wrote: > On Tue, 28 Apr 2009 11:59:18 -0700, Aaron Brady wrote: > >> To steal an idiom from Laura: Python has a float-shaped Nothing 0.0, a > >> list-shaped Nothing [], a dict-shaped Nothing {}, an int-shaped Nothing > >> 0, a singleton Nothing None, and so forth.
> > The sound of that metaphor is rather pleasing ('sweet nothings'), but > > I'm not so sure that metaphors belong in computer science and > > programming.
> Programming models the world, it isn't the world. Every model is a > metaphor. You can't get away from metaphors in programming, you can only > hide them and pretend they aren't there.
I was not aware that the intended use for 'True' was 'Something'. I thought it merely signified membership in a predicate or relation. 'GreaterThan( 3, 2 )', so '3> 2== True'. You might argue that numbers are metaphors for the world, since they are external to causality, have no temperature, etc., and likewise with logical predicates. But just because True is one metaphor, doesn't mean it is every metaphor. Is casting to a boolean a metaphor for a metaphor?
Mathematically, 'bool' injects mathematical objects into the set { True, False }. I would say it's a stretch to say that the empty list maps to the True value, and non-empty lists map to the False value. Mathematically, there's no reason to choose that mapping as the natural meaning and definition over any other, say 'list( x ) iff len( list( x ) )% 2'. (Some shells, I understand, suppose that there are multiple ways to fail, while others suppose that there are multiple ways to succeed.) In programming practice, there is a frequent division between empty lists and non-empty lists, so the author chose to map one case to one value, and the other case to the other.
> > Nothing can't have many shapes.
> In computing, you can't have a literal "nothing", because EVERYTHING > needs to be stored as a pattern of bits.
Correct... until memory gates can self-destruct. <cackle>
> In practice, for most high-level > languages, those bits are interpreted as a type as well as a value, so > the same bit pattern can mean different things according to what type it > is expected to be. Alternatively, the same information can be represented > in different bit patterns depending on how you interpret those bit > patterns.
> So in the context of computer programming, of course you can have nothing > with many "shapes": you have the number 0 represented as a single byte, a > 16-bit integer, a 32-bit integer, a long-int or BigNum, a pointer with > address 0, fixed point decimals of various sizes, Binary Coded Decimal, a > rational, a single float 0.0, a double float 0.0, a string of "tally > marks" without any tally, and so on, all of them in big-endian and little- > endian formats.
> > Having no onions is the same as having no carrots.
> "If you have one onion and I take it away, how many onions do you have > left?"
> If you answered "no carrots", I'd consider that a bizarre and unhelpful > answer, and wonder what you possibly thought carrots had to do with my > question.
> "Nothing" is not an absolute. "There is no wind" is not the same thing as > "there is no money left in my bank account".
> > If the different shapes of nothing don't > > compare equal to each other, which they don't, then they aren't all the > > same thing in different shapes.
> Who said they were the same thing?
The fact that bool( [] ) == bool( {} ). Merely that 'f( x )== f( y )' does not imply that 'x== y'. I am not arguing that '[]== {}', and I'm pretty sure you aren't either. However, x and y do form an equivalence class under 'f', IIRC.
If you ask of (blank), 'Is there anything?', which is what you state the 'bool' function means to do, there are only two answers: 'Yes, there is something', and 'No, there is nothing'.
> > Furthermore, it is awfully presumptuous to give objects a default > > 'nothing-ness' of 'something'. If anything, they should be nothing by > > default.
> That's a stupid idea.
[argument] snip
Fine, withdrawn. They shouldn't have one.
> > Conversion to other primitives is very picky; why should > > Boolean be so tolerant?
> Because it is useful and meaningful to ask whether an arbitrary object > represents something or nothing, but it's not useful or meaningful to ask > what integer is equivalent to an arbitrary object.
It's more common for it to make sense to divide a set into two pieces than it is to divide it into N pieces, the cardinality of the integers. But that doesn't make the presumed implementation 'return True' for an entire type.
I think the closest you could come would be to try the '__len__' method, and raise an exception if there isn't one. But if '__len__' is defined, then there is also a mapping from the type into the integers. By your logic, 'int( object )' should default to '__len__' as well, since the mapping is defined!
The 'bool' function means to ask, 'What Boolean value is this object most like?'. The object's type should ascertain something about the object, and answer. But that is not what happens. Python's implementation ignores the object completely, and answers blindly.
On Wed, 29 Apr 2009 17:35:28 +0200, Marco Mariani wrote: > Bruno Desthuilliers wrote:
>> Lawrence D'Oliveiro a écrit :
>>>> What is the rationale for considering all instances true of a user- >>>> defined type?
>>> It's a stupid idea,
>> Nope, it's a very sensible default (given you can redefine the >> 'nothingness' value of your types instances), specially when the >> language doesn't have a proper boolean type (which was the case for >> Python until 2.2 or 2.3, can't remember exactly).
> Man, you've given a serious answer to a sarcastic reply to an OP who has > been -- for years -- second in trolliness only to Xah Lee.
> Either that, or I have to replace my humor detector.
Aaron (castironpi) certainly used to be a major troll, but he got better. I know, I know, sometimes it's hard to tell if he's trolling or just engaging in flights of fancy, but I think it's mostly the later.
Lawrence's reply wasn't sarcastic -- he really does think that having every object be meaningful in a boolean context is stupid.
I think he's not just wrong, but badly wrong. To me, "if bool(x):" is barely better than "if bool(x) == True:", which in turn is not much better than "if (bool(x) == True) == True:".
The reason why Lawrence's insistence is so badly wrong becomes more apparent if you look at what you can do with boolean contexts other than simple `if` tests. Compare:
for x in a or b or c: do_something_with(x)
versus:
if len(a) > 0: temp = a elif len(b) > 0: temp = b elif len(c) > 0: temp = c for x in temp: do_something_with(x)
D'Aprano wrote: > The reason why Lawrence's insistence is so badly wrong becomes more > apparent if you look at what you can do with boolean contexts other than > simple `if` tests. Compare:
> for x in a or b or c: > do_something_with(x)
> versus:
> if len(a) > 0: > temp = a > elif len(b) > 0: > temp = b > elif len(c) > 0: > temp = c > for x in temp: > do_something_with(x)
I have never written anything so unbelievable in my life. And I hope I never will.
On Fri, 01 May 2009 00:22:22 -0700, Paul Rubin wrote: > Steven D'Aprano <ste...@REMOVE.THIS.cybersource.com.au> writes: >> for x in a or b or c: >> do_something_with(x)
> Ugh!!!!
> for x in [a,b,c]: > if len(x) > 0: > do_something_with(x) > break
What ugly, wasteful code. And it's *wrong* -- it doesn't do what my code does.
(1) Why build a list [a, b, c] that you don't need?
(2) Why assume that a, b and c are sequences with a fast __len__ method? They might be (say) linked lists that take O(N) to calculate the length, or binary trees that don't even have a length, but can be iterated over.
(3) And your code is wrong. I pass each element of the first non-empty sequence to do_something_with(). You pass the entire sequence. To do what my code does, you would need a nested for-loop like this:
for seq in [a,b,c]: if len(seq) > 0: for x in seq: do_something_with(x) break
Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> writes: > (2) Why assume that a, b and c are sequences with a fast __len__ method? > They might be (say) linked lists that take O(N) to calculate the length, > or binary trees that don't even have a length, but can be iterated over.
Why assume they have a bool method? Or a __or__ operator?
> for seq in [a,b,c]: > if len(seq) > 0: > for x in seq: > do_something_with(x) > break
Eh.
for seq in [a,b,c]: if sum(1 for x in imap(do_something_with, seq)) > 0: break
