On 2006-10-29, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Sun, 29 Oct 2006 00:31:23 -0700, Carl Banks wrote:
>
> That's why (for example) Python allows + to operate on lists, or strings,
> or floats
That was IMO a mistake. There are types for which concatenation as well as
addition are meanin
Steven D'Aprano wrote:
> It isn't often that I make an appeal to authority, but this is one of
> them. No offense, but when it comes to language design its a brave or
> foolish programmer who bucks the language idioms that Guido chose.
Well, it's pretty clear you consider some abstact notion of un
On Sun, 29 Oct 2006 00:31:23 -0700, Carl Banks wrote:
> Steven D'Aprano wrote:
>> Carl Banks:
>> > Overall, your objections don't really apply, since you're arguing what
>> > ought to be whereas my argument is pragmatic. Practically speaking, in
>> > realistic situations, "if len(a)>0" will work
Chetan wrote:
>>> I am joining after some network downtime here, so I seem to have missed what
>>> the real issue here is. At the risk of being completely irrelevant to the
>>> discussion here, I think it doesn't seem to be just about something or
>>> nothing - is None something or nothing? It see
Steven D'Aprano wrote:
> Carl Banks:
> > Overall, your objections don't really apply, since you're arguing what
> > ought to be whereas my argument is pragmatic. Practically speaking, in
> > realistic situations, "if len(a)>0" will work for a wider range of types
> > than "if a:".
>
> Well, that's
Georg Brandl <[EMAIL PROTECTED]> writes:
> Chetan wrote:
>>> Steven D'Aprano wrote:
>>> > On Sat, 28 Oct 2006 03:13:42 +0100, Steve Holden wrote:
>>> >
>>> >>> Finally, while True/False is a good mental mapping for numeric
>>> >>> comparisons,
>>> >>> take the following:
>>> >>>
>>> >>> >>> if
Chetan wrote:
>> Steven D'Aprano wrote:
>> > On Sat, 28 Oct 2006 03:13:42 +0100, Steve Holden wrote:
>> >
>> >>> Finally, while True/False is a good mental mapping for numeric
>> >>> comparisons,
>> >>> take the following:
>> >>>
>> >>> >>> if "Cliff is a pillar of the open source community":
>>
Gabriel Genellina <[EMAIL PROTECTED]> writes:
> At Friday 27/10/2006 23:13, Steve Holden wrote:
>
>>J. Clifford Dyer wrote:
>> > the one thing that Ms. Creighton points out that I can't get past is
>> > that Python, even with its bool type, *still* evaluates somethingness
>> > and nothingness, and
> Steven D'Aprano wrote:
> > On Sat, 28 Oct 2006 03:13:42 +0100, Steve Holden wrote:
> >
> >>> Finally, while True/False is a good mental mapping for numeric
> >>> comparisons,
> >>> take the following:
> >>>
> >>> >>> if "Cliff is a pillar of the open source community":
> >>> print "t
On Sat, 28 Oct 2006 03:24:50 -0700, Carl Banks wrote:
> Not all objects that have a state of emptiness consider emptiness to be
> false.
In which case they should define __nonzero__ appropriately.
In which case, calling code that assumes that len(obj) is a substitute for
truth-testing will do th
Steven D'Aprano wrote:
> On Sat, 28 Oct 2006 03:13:42 +0100, Steve Holden wrote:
>
>>> Finally, while True/False is a good mental mapping for numeric
>>> comparisons, take the following:
>>>
>>> >>> if "Cliff is a pillar of the open source community":
>>> print "thank you"
>>> e
J. Clifford Dyer wrote:
> Georg Brandl wrote:
>> J. Clifford Dyer wrote:
>>
>>> >>> (1 > 0) < 1
>>> False
>>> >>> 1 > 0 < 1
>>> True
>>> >>> 1 > (0 < 1)
>>> False
>>> >>> 10 > (0 < 1)
>>> True
>>
>> I hope you know why this works the way it does.
>>
>> Georg
>
> Yes, I do understand why it
Georg Brandl wrote:
> J. Clifford Dyer wrote:
>
>> >>> (1 > 0) < 1
>> False
>> >>> 1 > 0 < 1
>> True
>> >>> 1 > (0 < 1)
>> False
>> >>> 10 > (0 < 1)
>> True
>
> I hope you know why this works the way it does.
>
> Georg
Yes, I do understand why it works. I couldn't have crafted it if I
did
On 2006-10-28, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Fri, 27 Oct 2006 17:35:58 +, Antoon Pardon wrote:
>
>> On 2006-10-27, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>>
>> So
>> it seems that python has generalised the len function to provide
>> the number of elements in the containe
On 2006-10-28, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Fri, 27 Oct 2006 18:22:28 +, Antoon Pardon wrote:
>
And how do I express that a number has to be greater than
100 into a Nothing vs Something dichotomy? Declare all
greater numbers as Something and the rest as Nothing
On Sat, 28 Oct 2006 11:42:42 +0200, Marc 'BlackJack' Rintsch wrote:
> In <[EMAIL PROTECTED]>, Steven
> D'Aprano wrote:
>
>> On Fri, 27 Oct 2006 11:25:09 -0700, Carl Banks wrote:
>>
>>> Iterators do have overlapping uses with lists, but the "if a:" doesn't
>>> work for them, so it's moot.
>>
>>
J. Clifford Dyer wrote:
> >>> (1 > 0) < 1
> False
> >>> 1 > 0 < 1
> True
> >>> 1 > (0 < 1)
> False
> >>> 10 > (0 < 1)
> True
I hope you know why this works the way it does.
Georg
--
http://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano wrote:
> On Fri, 27 Oct 2006 11:25:09 -0700, Carl Banks wrote:
>
> > Steven D'Aprano wrote:
> >> But in this specific instance, I don't see any advantage to explicitly
> >> testing the length of a list. Antoon might think that is sufficiently
> >> polymorphic, but it isn't. He cares
In <[EMAIL PROTECTED]>, Steven
D'Aprano wrote:
> On Fri, 27 Oct 2006 11:25:09 -0700, Carl Banks wrote:
>
>> Iterators do have overlapping uses with lists, but the "if a:" doesn't
>> work for them, so it's moot.
>
> Sure it works for iterators.
>
it = iter([0])
bool(it)
> True
it.
On Fri, 27 Oct 2006 11:25:09 -0700, Carl Banks wrote:
> Steven D'Aprano wrote:
>> But in this specific instance, I don't see any advantage to explicitly
>> testing the length of a list. Antoon might think that is sufficiently
>> polymorphic, but it isn't. He cares whether the object has zero _leng
On Fri, 27 Oct 2006 18:22:28 +, Antoon Pardon wrote:
>>> And how do I express that a number has to be greater than
>>> 100 into a Nothing vs Something dichotomy? Declare all
>>> greater numbers as Something and the rest as Nothing?
>>
>> Well, would you declare numbers less than 100 False?
>
On Fri, 27 Oct 2006 17:35:58 +, Antoon Pardon wrote:
> On 2006-10-27, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>
>> But in this specific instance, I don't see any advantage to explicitly
>> testing the length of a list. Antoon might think that is sufficiently
>> polymorphic, but it isn't. H
On Sat, 28 Oct 2006 03:13:42 +0100, Steve Holden wrote:
>> Python is not evaluating the truth of the matter, but, as Ms. Creighton
>> would say, the "somethingness" of that which 10 > 5 evaluates to. (1
>> aka True)
>>
> >>> type(10>5)
>
> >>>
>
> It does seem that there is a specific t
At Friday 27/10/2006 23:13, Steve Holden wrote:
J. Clifford Dyer wrote:
> the one thing that Ms. Creighton points out that I can't get past is
> that Python, even with its bool type, *still* evaluates somethingness
> and nothingness, and True and False are just numbers with hats on.
>
> >>> Tru
J. Clifford Dyer wrote:
> I do see how mapping to Truth/Falsehood is more natural, and I do
> believe that one of the great things about python is that it feels
> natural in so many ways, and hence makes it easy to produce code, but
> the one thing that Ms. Creighton points out that I can't get
I do see how mapping to Truth/Falsehood is more natural, and I do
believe that one of the great things about python is that it feels
natural in so many ways, and hence makes it easy to produce code, but
the one thing that Ms. Creighton points out that I can't get past is
that Python, even with
On Fri, 27 Oct 2006 11:25:09 -0700
Carl Banks <[EMAIL PROTECTED]> wrote:
#> P.S. binary trees do have length: it's the number of nodes, just as
#> the number of keys is the length of a dict. I can't think of any
#> objects that use indexing but don't have a length,
Well, infinite lists (either ci
On 2006-10-27, Donn Cave <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Antoon Pardon <[EMAIL PROTECTED]> wrote:
> ...
>> I think you are incorrect.
>
> Thanks! I rest my case!
>
>> And how do I express that a number has to be greater than
>> 100 into a Nothing vs Something dichot
Steven D'Aprano wrote:
> But in this specific instance, I don't see any advantage to explicitly
> testing the length of a list. Antoon might think that is sufficiently
> polymorphic, but it isn't. He cares whether the object has zero _length_,
> but for true polymorphism, he should be caring about
On 2006-10-27, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Fri, 27 Oct 2006 09:16:57 +, Antoon Pardon wrote:
>
>>> I think it is a good time to remind people of some extremely well-thought
>>> out opposition to the introduction of bools to Python from Laura Creighton:
>>>
>>> http://mail.py
On 2006-10-27, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> But in this specific instance, I don't see any advantage to explicitly
> testing the length of a list. Antoon might think that is sufficiently
> polymorphic, but it isn't. He cares whether the object has zero _length_,
> but for true poly
In article <[EMAIL PROTECTED]>,
Antoon Pardon <[EMAIL PROTECTED]> wrote:
...
> I think you are incorrect.
Thanks! I rest my case!
> And how do I express that a number has to be greater than
> 100 into a Nothing vs Something dichotomy? Declare all
> greater numbers as Something and the rest as N
On Fri, 27 Oct 2006 12:54:35 +0100, Steve Holden wrote:
> Antoon Pardon wrote:
>> On 2006-10-27, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>>
>>>Antoon Pardon wrote:
>>>
>>>
>since you never publish any code,
This is not True. You shouldn't confuse your lack of recollection
with r
***
Your mail has been scanned by InterScan MSS.
***
On Thursday 26 October 2006 02:56, John Salerno wrote:
> >>> s = 'hello'
> >>> s == True
> False
> >>> if s:
> print 'hi'
>
this isn't only a python behavior.
the "if" test is valid for all no
On Fri, 27 Oct 2006 09:16:57 +, Antoon Pardon wrote:
>> I think it is a good time to remind people of some extremely well-thought
>> out opposition to the introduction of bools to Python from Laura Creighton:
>>
>> http://mail.python.org/pipermail/python-list/2002-April/095878.html
>>
>> She l
Antoon Pardon wrote:
> On 2006-10-27, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>>
>>
since you never publish any code,
>>>
>>>This is not True. You shouldn't confuse your lack of recollection
>>>with reality.
>>
>>pointers, please.
>
>
> Sorry, the answer is no. I do
Antoon Pardon wrote:
> On 2006-10-27, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>>
>>
since you never publish any code,
>>>
>>>This is not True. You shouldn't confuse your lack of recollection
>>>with reality.
>>
>>pointers, please.
>
>
> Sorry, the answer is no. I do
On 2006-10-27, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>> since you never publish any code,
>>
>> This is not True. You shouldn't confuse your lack of recollection
>> with reality.
>
> pointers, please.
Sorry, the answer is no. I don't care whether you can locate my code
Antoon Pardon wrote:
>> since you never publish any code,
>
> This is not True. You shouldn't confuse your lack of recollection
> with reality.
pointers, please.
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-10-27, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> The latter will treat None and False the same as [], () and {},
>> which in most of my code is not what I want.
>
> since you never publish any code,
This is not True. You shouldn't confuse your lack of recollectio
On 2006-10-26, Steve Holden <[EMAIL PROTECTED]> wrote:
> John Coleman wrote:
>> As far as using non-booleans as conditions - I just think that if you
>> want a certain block of code to be executed only if, for example, a
>> list is non-empty, why not *say* so? I think "if my_list != []:" just
>> r
Antoon Pardon wrote:
> The latter will treat None and False the same as [], () and {},
> which in most of my code is not what I want.
since you never publish any code, what you do in your code is not very
interesting to anyone.
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-10-26, Donn Cave <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Holden <[EMAIL PROTECTED]> wrote:
> ...
>> Maybe so, but that "rule" (and let's not forget that the zen is not
>> actually a set of prescriptive rules but rather guidelines for the
>> informed) is immed
On 2006-10-26, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Oct 2006 19:19:59 +, John Salerno wrote:
>
>> Oh!!! I get it now! I was thinking that
>>
>> if s
>>
>> was the same as
>>
>> if s == True
>
> No. But you know that now :)
>
>> because I know sometimes you can write if sta
Ben Finney wrote:
> Gabriel Genellina <[EMAIL PROTECTED]> writes:
>
> > At Wednesday 25/10/2006 23:29, Paul Rubin wrote:
> > >Steve Holden <[EMAIL PROTECTED]> writes:
> > >I get that iter(()) is True (Python 2.3.4).
> >
> > It's False on 2.4.2 - and perhaps it's what one would expect, but
> > since
Ben Finney wrote:
> Gabriel Genellina <[EMAIL PROTECTED]> writes:
>
>
>>At Wednesday 25/10/2006 23:29, Paul Rubin wrote:
>>
>>>Steve Holden <[EMAIL PROTECTED]> writes:
>>>I get that iter(()) is True (Python 2.3.4).
>>
No I didn't - that was Paul Rubin.
>>It's False on 2.4.2 - and perhaps it's wh
At Thursday 26/10/2006 19:57, Ben Finney wrote:
Gabriel Genellina <[EMAIL PROTECTED]> writes:
> At Wednesday 25/10/2006 23:29, Paul Rubin wrote:
> >Steve Holden <[EMAIL PROTECTED]> writes:
> >I get that iter(()) is True (Python 2.3.4).
>
> It's False on 2.4.2 - and perhaps it's what one would ex
Gabriel Genellina <[EMAIL PROTECTED]> writes:
> At Wednesday 25/10/2006 23:29, Paul Rubin wrote:
> >Steve Holden <[EMAIL PROTECTED]> writes:
> >I get that iter(()) is True (Python 2.3.4).
>
> It's False on 2.4.2 - and perhaps it's what one would expect, but
> since this behavior is not documented
At Wednesday 25/10/2006 23:29, Paul Rubin wrote:
Steve Holden <[EMAIL PROTECTED]> writes:
> Gabriel Genellina wrote:
> > iter(())
I get that iter(()) is True (Python 2.3.4).
It's False on 2.4.2 - and perhaps it's what one would expect, but
since this behavior is not documented anywhere, one
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> wrote:
...
> Maybe so, but that "rule" (and let's not forget that the zen is not
> actually a set of prescriptive rules but rather guidelines for the
> informed) is immediately preceded by the most important "rule" of all:
> "Beau
On Wed, 25 Oct 2006 19:19:59 +, John Salerno wrote:
> Oh!!! I get it now! I was thinking that
>
> if s
>
> was the same as
>
> if s == True
No. But you know that now :)
> because I know sometimes you can write if statements this way (though
> it's wordy).
You can, but shouldn't.
> Bu
Skip> string ""
Skip> list[]
Skip> tuple ()
Skip> dict{}
Skip> int 0
Skip> float 0.0
Skip> complex 0j
Skip> set set()
John Coleman wrote:
> Donn Cave wrote:
>
>>In article <[EMAIL PROTECTED]>,
>> "John Coleman" <[EMAIL PROTECTED]> wrote:
>>
>>
>>>Very good point, though one could argue perhaps that when one is
>>>comparing an object with a truth value then one is implicitly asking
>>>for the truth value of that o
Donn Cave wrote:
> In article <[EMAIL PROTECTED]>,
> "John Coleman" <[EMAIL PROTECTED]> wrote:
>
> > Very good point, though one could argue perhaps that when one is
> > comparing an object with a truth value then one is implicitly asking
> > for the truth value of that object
>
> On the contrary
"Robert Kern" <[EMAIL PROTECTED]> wrote:
8<--
> It's a bit of an abuse on the English language, but what isn't in software?
jumps used not to be
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
John Coleman wrote:
> Paul Rubin wrote:
> > "John Coleman" <[EMAIL PROTECTED]> writes:
> > > > then "x == 3" is false, but "int(x) == 3" is true.
> > > But then why is 3.0 == 3 true? They are different types.
> >
> > The 3 gets converted to float, like when you say
> >
> > x = 3.1 + 3
> >
> > th
Paul Rubin <"http://phr.cx"@NOSPAM.invalid> writes:
> Max Erickson <[EMAIL PROTECTED]> writes:
> > > [Steve:] There's still a very obvious omission ...
> >
> > bool.
> >
> > unicode and long if you are fussy.
>
> There's another. Imagine a datatype for Discordian religious
> leaders and conside
Max Erickson <[EMAIL PROTECTED]> writes:
> > [Steve:] There's still a very obvious omission ...
>
> bool.
>
> unicode and long if you are fussy.
There's another. Imagine a datatype for Discordian religious leaders
and consider what a genderless one would be called.
--
http://mail.python.org/ma
Steve Holden <[EMAIL PROTECTED]> wrote:
> Gabriel Genellina wrote:
>> At Wednesday 25/10/2006 22:29, Terry Reedy wrote:
>>
>>> >> the string class's "nil" value. Each of the builtin types
>>> >> has such an "empty" or "nil" value:
>>> >>
>>> >> string ""
>>> >> list
Steve Holden <[EMAIL PROTECTED]> writes:
> Gabriel Genellina wrote:
> > Just for fun:
> > buffer('')
> > frozenset()
> > iter(())
> > xrange(0)
I get that iter(()) is True (Python 2.3.4).
> [Steve:] There's still a very obvious omission ...
Hehehe...
--
http://mail.python.org/mailman/listinfo/p
Steve Holden <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > Each of the builtin types has such an "empty" or "nil" value:
> >
> > string ""
> > list[]
> > tuple ()
> > dict{}
> > int 0
> >
Gabriel Genellina wrote:
> At Wednesday 25/10/2006 22:29, Terry Reedy wrote:
>
>> >> the string class's "nil" value. Each of the builtin types has such an
>> >> "empty" or "nil" value:
>> >>
>> >> string ""
>> >> list[]
>> >> tuple ()
>> >>
At Wednesday 25/10/2006 22:29, Terry Reedy wrote:
>> the string class's "nil" value. Each of the builtin types has such an
>> "empty" or "nil" value:
>>
>> string ""
>> list[]
>> tuple ()
>> dict{}
>> int
"Steve Holden" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> the string class's "nil" value. Each of the builtin types has such an
>> "empty" or "nil" value:
>>
>> string ""
>> list[]
>> tuple ()
>> dict
Steve Holden <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > s is not equal to the boolean object True, but it also doesn't
> > evaluate to the string class's "nil" value. Each of the builtin
> > types has such an "empty" or "nil" value:
> >
> > string ""
> > list
George Sakkis wrote:
> Martin v. Löwis wrote:
>> Not-so-obviously, arbitrary user-defined values can also be
>> treated as false: If they implement __nonzero__, they are
>> false if False is returned from __nonzero__; otherwise,
>> if they implement __len__, they are false if 0 is returned
>> from
On 2006-10-25, John Coleman <[EMAIL PROTECTED]> wrote:
>
> Paul Rubin wrote:
>> John Salerno <[EMAIL PROTECTED]> writes:
>> > I'm a little confused. Why doesn't s evaluate to True in the first
>> > part, but it does in the second? Is the first statement something
>> > different?
>>
>> No. True and
Paul Rubin wrote:
> John Salerno <[EMAIL PROTECTED]> writes:
>
>>if (10 > 5)
>>would be the same as
>>if (10 > 5) == True
>
>
> Yes.
Though it would be bad style to write it in the latter way, not to
mention less efficient.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3
John Coleman wrote:
> Martin v. Löwis wrote:
>
>>John Coleman schrieb:
>>
>>>Yes - it just seems that there isn't a principled reason for implicitly
>>>converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to
>>>boolean in "cat" == true.
>>
>>Sure there is: equality should be transit
[EMAIL PROTECTED] wrote:
> John> I'm a little confused. Why doesn't s evaluate to True in the first
> John> part, but it does in the second? Is the first statement something
> John> different?
>
> >>> s = 'hello'
> >>> s == True
> False
> >>> if s:
> ... pri
In article <[EMAIL PROTECTED]>,
"John Coleman" <[EMAIL PROTECTED]> wrote:
> Very good point, though one could argue perhaps that when one is
> comparing an object with a truth value then one is implicitly asking
> for the truth value of that object
On the contrary -- since there is normally no n
Martin v. Löwis wrote:
> [EMAIL PROTECTED] schrieb:
> > the string class's "nil" value. Each of the builtin types has such an
> > "empty" or "nil" value:
> >
> > string ""
> > list[]
> > tuple ()
> > dict{}
> > int
Martin v. Löwis wrote:
> John Coleman schrieb:
> > Yes - it just seems that there isn't a principled reason for implicitly
> > converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to
> > boolean in "cat" == true.
>
> Sure there is: equality should be transitive. So while we have
> 3
John Coleman schrieb:
> Yes - it just seems that there isn't a principled reason for implicitly
> converting 3 to 3.0 in 3.0 == 3 but not implicitly converting "cat" to
> boolean in "cat" == true.
Sure there is: equality should be transitive. So while we have
3 == 3L == 3.0 == 3.0+0j
and can there
[EMAIL PROTECTED] schrieb:
> the string class's "nil" value. Each of the builtin types has such an
> "empty" or "nil" value:
>
> string ""
> list[]
> tuple ()
> dict{}
> int 0
> float
Paul Rubin wrote:
> "John Coleman" <[EMAIL PROTECTED]> writes:
> > > then "x == 3" is false, but "int(x) == 3" is true.
> > But then why is 3.0 == 3 true? They are different types.
>
> The 3 gets converted to float, like when you say
>
> x = 3.1 + 3
>
> the result is 6.1.
Yes - it just seems th
> So I suppose
>
> if (10 > 5)
>
> would be the same as
>
> if (10 > 5) == True
>
> because (10 > 5) does evaluate to "True".
Yes...and similarly,
if ((10 > 5) == True) == True
for the same reason...as does
if (((10 > 5) == True) == True) == True
as does... :*)
-tkc
--
http://mail.pyt
Robert Kern wrote:
> They are, indeed, quite different things. Finding the truth value of an
> object is not the same thing as testing if the object is equal to the
> object True.
Yeah, I had this in the back of my mind, but I was thinking that this
test would be written as
if s is True
And
John Coleman wrote:
> But then why is 3.0 == 3 true? They are different types.
>
Good question. Does one type get converted to the other automatically?
That's all I can think of...
--
http://mail.python.org/mailman/listinfo/python-list
John Salerno <[EMAIL PROTECTED]> writes:
> if (10 > 5)
> would be the same as
> if (10 > 5) == True
Yes.
--
http://mail.python.org/mailman/listinfo/python-list
"John Coleman" <[EMAIL PROTECTED]> writes:
> > then "x == 3" is false, but "int(x) == 3" is true.
> But then why is 3.0 == 3 true? They are different types.
The 3 gets converted to float, like when you say
x = 3.1 + 3
the result is 6.1.
--
http://mail.python.org/mailman/listinfo/python-list
> I'm a little confused. Why doesn't s evaluate to True in the first part,
> but it does in the second? Is the first statement something different?
>
> >>> s = 'hello'
> >>> s == True
> False
> >>> if s:
> print 'hi'
The "if s" does an implicit (yeah, I know, "explicit is better
than
John Salerno wrote:
> I'm a little confused. Why doesn't s evaluate to True in the first part,
> but it does in the second? Is the first statement something different?
>
> >>> s = 'hello'
> >>> s == True
> False
> >>> if s:
> print 'hi'
"true" != "True". comparing a value to another v
John Salerno wrote:
> I'm a little confused. Why doesn't s evaluate to True in the first part,
> but it does in the second? Is the first statement something different?
>
> >>> s = 'hello'
> >>> s == True
> False
> >>> if s:
> print 'hi'
>
>
> hi
> >>>
They are, indeed, quite
Paul Rubin wrote:
> No. True and False are boolean values, where booleans are a different
> data type from strings, just like strings are different from integers.
>
> >>> if s:
> print 'hi'
>
> converts s to a boolean during evaluation.
Oh!!! I get it now! I was thinking that
if s
w
Paul Rubin wrote:
> John Salerno <[EMAIL PROTECTED]> writes:
> > I'm a little confused. Why doesn't s evaluate to True in the first
> > part, but it does in the second? Is the first statement something
> > different?
>
> No. True and False are boolean values, where booleans are a different
> data
John Salerno wrote:
> I'm a little confused. Why doesn't s evaluate to True in the first part,
> but it does in the second? Is the first statement something different?
>
> >>> s = 'hello'
> >>> s == True
> False
> >>> if s:
> print 'hi'
>
>
> hi
> >>>
>
> Thanks.
Excellent question!
John Salerno <[EMAIL PROTECTED]> writes:
> I'm a little confused. Why doesn't s evaluate to True in the first
> part, but it does in the second? Is the first statement something
> different?
No. True and False are boolean values, where booleans are a different
data type from strings, just like st
John> I'm a little confused. Why doesn't s evaluate to True in the first
John> part, but it does in the second? Is the first statement something
John> different?
>>> s = 'hello'
>>> s == True
False
>>> if s:
... print 'hi'
hi
s is not equal to the bool
89 matches
Mail list logo
