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 meaningfull
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 True and
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:
print thank you
else:
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 Cliff is a pillar of the open source
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 a quantitative
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 seems to be
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 for a wider
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
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(105)
type 'bool'
It does seem that there is a specific type
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. He cares
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?
No but the
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 _length_,
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.next()
0
bool(it)
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 whether the
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
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.
Sure it works for
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?
Well, would
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 container.
Sure. But
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
didn't, but my point is that the reason why
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 works. I couldn't have crafted it if I
didn't, but my
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 the
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
else:
print
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
else:
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 statements this way
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 immediately preceded
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.
/F
--
http://mail.python.org/mailman/listinfo/python-list
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
reads better
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 recollection
with
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.
/F
--
http://mail.python.org/mailman/listinfo/python-list
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
or not or
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 don't care whether you can
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 don't care whether you can
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 lost the
***
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 non-zero
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 reality.
pointers, please.
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 Nothing?
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
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:
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, 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 dichotomy? Declare all
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
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
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
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.
True + 3
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
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 -- since there
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 object
On the contrary
Skip string
Skip list[]
Skip tuple ()
Skip dict{}
Skip int 0
Skip float 0.0
Skip complex 0j
Skip set set()
Skip
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.
But what I
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:
Beautiful is
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
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 anywhere,
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 expect, but
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 what one would expect,
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 this behavior is
Carl Banks [EMAIL PROTECTED] writes:
An iterator is not a sequence, and it's impossible to determine
whether an iterator is empty in general, except by trying to get
an item from it. [...]
IMO, this is big time wart in the language. Iterators have no
calculatable truth value; for many
Ben Finney wrote:
Would it make sense to *define* a truth value for iterators? Or at
least to enable those that *are* able to say I'm empty to do so in a
way that boolean contexts can interpret as false?
Perhaps allowing (but not requiring) an iterator object to grow a
'len' method is the
Ben Finney wrote:
Carl Banks [EMAIL PROTECTED] writes:
An iterator is not a sequence, and it's impossible to determine
whether an iterator is empty in general, except by trying to get
an item from it. [...]
IMO, this is big time wart in the language. Iterators have no
calculatable
Robert Kern wrote:
Ben Finney wrote:
Would it make sense to *define* a truth value for iterators? Or at
least to enable those that *are* able to say I'm empty to do so in a
way that boolean contexts can interpret as false?
Perhaps allowing (but not requiring) an iterator object to
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.
--
http://mail.python.org/mailman/listinfo/python-list
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 boolean object
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
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! This should help:
s =
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 type from
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
was the
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 different things.
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 value isn't the same
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 implicit)
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
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 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
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 I
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
--
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 that there isn't a
[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 0.0
complex
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 therefore
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 == 3L == 3.0
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 0
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 need to
[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:
... print 'hi'
hi
s
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 transitive. So while we have
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 3119
Holden Web
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 False are boolean
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 __len__.
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[]
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{}
int
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 0
float
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 ()
dict{}
int
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
float
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/python-list
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[]
tuple ()
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.
--
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 consider what a genderless
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
the result is 6.1.
Yes - it
94 matches
Mail list logo
