Op 2005-12-15, Grant Edwards schreef [EMAIL PROTECTED]:
On 2005-12-15, Antoon Pardon [EMAIL PROTECTED] wrote:
Well, in my case, a given name (or return value) is always
bound to a floating point object. I don't test the type of the
object and treat it in two different ways depending on what
On 2005-12-16, Antoon Pardon [EMAIL PROTECTED] wrote:
Your examples are still both very different from the NaN
example. A NaN is a floating point operation that supports all
the same operations as all other floating point operations. In
your example an integer object of -2 does not support
Op 2005-12-14, Grant Edwards schreef [EMAIL PROTECTED]:
On 2005-12-14, Antoon Pardon [EMAIL PROTECTED] wrote:
Well, as you might argue, I'm not tryng to effect a change in
your behaviour, I'm simply trying to point out how it could be
made more rational.
[...]
Or return NaN instead of
Antoon Pardon wrote:
Op 2005-12-14, Grant Edwards schreef [EMAIL PROTECTED]:
On 2005-12-14, Antoon Pardon [EMAIL PROTECTED] wrote:
Well, as you might argue, I'm not tryng to effect a change in
your behaviour, I'm simply trying to point out how it could be
made more rational.
[...]
Op 2005-12-14, Mike Meyer schreef [EMAIL PROTECTED]:
[EMAIL PROTECTED] writes:
Steve Holden wrote:
It would be somewhat more self-documenting, but why not just use one
name to indicate the state and another, only meaningful in certain
states, to indicate the callback?
Why should I do that?
On 2005-12-15, Antoon Pardon [EMAIL PROTECTED] wrote:
Or return NaN instead of raising exception for numeric
functions ?
Because usually (in my applications anyway) NaN is a perfectly
valid value and not an exception case that needs to be
handled.
I don't see the difference. In my
Op 2005-12-13, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
Op 2005-12-13, Chris Mellon schreef [EMAIL PROTECTED]:
[...]
If you have a consistent API and you're checking for error values from
your GTK functions, then you already have a lot more code than using 2
varaibles will
Antoon Pardon wrote:
Op 2005-12-13, Steve Holden schreef [EMAIL PROTECTED]:
[...]
But lets make an effort to make the code more readable. What
about the following suggestion. I use a kind of EnumType with
two values: NotRegistered and Registerd. And the name of the
type is NotConnected. So I can
Steve Holden wrote:
It would be somewhat more self-documenting, but why not just use one
name to indicate the state and another, only meaningful in certain
states, to indicate the callback?
Why should I do that? Checking the type of a variable is conceptually
no different form testing
Op 2005-12-14, Steve Holden schreef [EMAIL PROTECTED]:
Antoon Pardon wrote:
It would be somewhat more self-documenting, but why not just use one
name to indicate the state and another, only meaningful in certain
states, to indicate the callback?
Why should I do that? Checking the type of
On 2005-12-14, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Well, as you might argue, I'm not tryng to effect a change in your
behaviour, I'm simply trying to point out how it could be made more
rational.
What would be the difference in his usage and allowing Null in a RDBMS
column?
Don't
Op 2005-12-14, Grant Edwards schreef [EMAIL PROTECTED]:
On 2005-12-14, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Well, as you might argue, I'm not tryng to effect a change in your
behaviour, I'm simply trying to point out how it could be made more
rational.
What would be the difference in
[EMAIL PROTECTED] writes:
Steve Holden wrote:
It would be somewhat more self-documenting, but why not just use one
name to indicate the state and another, only meaningful in certain
states, to indicate the callback?
Why should I do that? Checking the type of a variable is conceptually
no
Mike Meyer wrote:
[EMAIL PROTECTED] writes:
Steve Holden wrote:
It would be somewhat more self-documenting, but why not just use one
name to indicate the state and another, only meaningful in certain
states, to indicate the callback?
Why should I do that? Checking the type of a
test for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values in list ? equality
returned True
So I changed my test for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity
, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values in list ? equality, it seems) ; did I
miss something
Steve Holden [EMAIL PROTECTED] writes:
The really interesting question your post raises, though, is Why do
you feel it's necessary to test to see whether a variable is a
Boolean?.
What's the point of having Booleans, if you can't tell them from integers?
--
changed my test for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
The really interesting question your post raises, though, is Why do
you feel it's necessary to test to see whether a variable is a
Boolean?.
What's the point of having Booleans, if you can't tell them from integers?
Because
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
The really interesting question your post raises, though, is Why do
you feel it's necessary to test to see whether a variable is a
Boolean?.
What's the point of having Booleans, if you can't tell them from integers?
Booleans are
Erik Max Francis wrote:
What's the point of having Booleans, if you can't tell them from integers?
Because
return True
is clearer than
return 1
if the purpose of the return value is to indicate a Boolean rather than
an arbitrary integer.
the real reason booleans were added was that
Carsten Haese wrote:
...
Where/how did you search? http://docs.python.org/lib/typesseq.html
states unambiguously that x in s returns True if an item of s is
equal to x, else False
.
exactly and I see
0==False
True
so I guess nothing is wrong :)
--
Robin Becker
--
Erik Max Francis wrote:
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
The really interesting question your post raises, though, is Why do
you feel it's necessary to test to see whether a variable is a
Boolean?.
What's the point of having Booleans, if you can't tell them
returned True
So I changed my test for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one
[EMAIL PROTECTED] wrote:
True, but if that is the only reason, Two built-in value of
True/False(0/1) serves the need which is what is now(well sort of). Why
have seperate types and distinguish them ?
Because of this:
x = True
y = 1 # but I mean it to represent true
Erik Max Francis wrote:
[EMAIL PROTECTED] wrote:
True, but if that is the only reason, Two built-in value of
True/False(0/1) serves the need which is what is now(well sort of). Why
have seperate types and distinguish them ?
Because of this:
x = True
y = 1 # but I mean it
[EMAIL PROTECTED] wrote:
True too, and could be the reason(or similar too) why the OP wants to
test the type rather than the logical value of it.
The type is for the self-documentation purposes. The value is the same;
so no, that's not a good reason either.
--
Erik Max Francis [EMAIL
wrote:
if the purpose of the return value is to indicate a Boolean rather than
an arbitrary integer.
True, but if that is the only reason, Two built-in value of
True/False(0/1) serves the need which is what is now(well sort of). Why
have seperate types and distinguish them ?
True == 1
Ok, I'll explain why I wanted to test if the value was a boolean
I have a program that generates HTML tags with attributes. The
principle is that
TAG('text',arg1=val1,arg2=val2)
generates
TAG arg1=val1 arg2=val2text/TAG
For HTML attributes that don't have an explicit value (such as the
SELECTED
Erik Max Francis wrote:
[EMAIL PROTECTED] wrote:
True too, and could be the reason(or similar too) why the OP wants to
test the type rather than the logical value of it.
The type is for the self-documentation purposes. The value is the same;
so no, that's not a good reason either.
I
Thanks for the link Carsten, the explanation is clear
I didn't know where to search in the Python documentation, there isn't
a section about keywords (always wondered why without daring to say -
now it's done). So I typed ' in operator Python ' in Google, which
gave :
- on the first page a link
I haven't read all of the responses to this thread, so perhaps this has
already been suggested. But it occurs to me that if one needs to
determine whether a variable is a bool or int it could be done like so:
Booltype = False
var = 0
Booltype == var
True
Booltype.__class__ == var.__class__
Duncan Booth wrote:
Another reason to have a boolean type is of course to provide a cast:
def isNameSet(self):
return boolean(self.name)
instead of:
def isNameSet(self):
if self.name:
return True
else:
return False
given that Python
wrote:
For HTML attributes that don't have an explicit value (such as the
SELECTED attribute in OPTION) the keyword argument to the function must
have the value True
A better way to do this (given that HTML defines exactly which attributes
do not take a value) is to use the attribute name
Fredrik Lundh wrote:
Duncan Booth wrote:
Another reason to have a boolean type is of course to provide a cast:
def isNameSet(self):
return boolean(self.name)
instead of:
def isNameSet(self):
if self.name:
return True
else:
Duncan Booth wrote:
For HTML attributes that don't have an explicit value (such as the
SELECTED attribute in OPTION) the keyword argument to the function must
have the value True
A better way to do this (given that HTML defines exactly which attributes
do not take a value) is to use the
[EMAIL PROTECTED] wrote:
I see you skip another use case of XMLRPC Duncan mentioned, is that a
valid reason ?
the PEP has the answer. also see my reply to Erik Max Francis:
http://groups.google.com/group/comp.lang.python/msg/adb5e9389ea20b3c
(the silly Boolean class in that post is taken
on 13.12.2005 11:39 Fredrik Lundh said the following:
Duncan Booth wrote:
Another reason to have a boolean type is of course to provide a cast:
def isNameSet(self):
return boolean(self.name)
[snip]
given that Python already had a function for this, that wasn't
much of a reason:
Duncan Booth wrote:
A better way to do this (given that HTML defines exactly which attributes
do not take a value) is to use the attribute name and simply generate the
attribute only if the value is non-false.
another approach (which may or may not be suitable in this case) is to
use the
cases and I eventually found that for v =
0 the test returned True
So I changed my test for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition
was a boolean, with this
test : if v in [True,False]
My script didn't work in some cases and I eventually found that for v =
0 the test returned True
So I changed my test for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched
Chris Mellon wrote:
Granted, of course, it's your code. But I wouldn't accept it in
anything I was in charge of.
That says it all. It is his code, whether you would accept it means
nothing. If you can point out that it is functionally wrong, it may
mean something. Otherise, it is nothing more
Op 2005-12-13, Chris Mellon schreef [EMAIL PROTECTED]:
However I must say the coupling in that interface has a very definite
code smell. Why not use two variables, a Boolean registered and an
integer ID that is meaningless when registered is False?
Because the integer ID can be meaningless
On 2005-12-13, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
but seriously, unless you're writing an introspection tool, testing for
bool is pretty silly. just use if v or if not v, and leave the rest
to
Python.
The OP's code(and
On 2005-12-13, Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
The really interesting question your post raises, though, is
Why do you feel it's necessary to test to see whether a
variable is a Boolean?.
What's the point of having Booleans, if you can't tell them
from integers?
Grant Edwards wrote:
He seems to be testing boolean type, not whether it is true
or false.
Right. But that's almost always pointless. Knowing whether a
variable is a boolean or not is very rarely useful. What one
wants to know is whether a varible is true or not. The code for
that is:
Fredrik Lundh [EMAIL PROTECTED] writes:
Duncan Booth wrote:
For HTML attributes that don't have an explicit value (such as the
SELECTED attribute in OPTION) the keyword argument to the function must
have the value True
A better way to do this (given that HTML defines exactly which
Mike Meyer wrote:
(for example, in img ismap, ismap is the value, not the attribute name.
it's up to the parser to figure out (from the DTD) that this value can only
be used by the ismap attribute, and interpret it as img ismap=ismap)
But this isn't necessarilly true: img alt=ismap is
Antoon Pardon wrote:
Op 2005-12-13, Chris Mellon schreef [EMAIL PROTECTED]:
[...]
If you have a consistent API and you're checking for error values from
your GTK functions, then you already have a lot more code than using 2
varaibles will cost you. 10 lines, maybe.
The fact that you think
Mike Meyer wrote:
But this isn't necessarilly true: img alt=ismap is perfectly legal.
mike
Legal but irrelevant since the ALT attribute cannot be minimized.
--
http://mail.python.org/mailman/listinfo/python-list
On Tue, 13 Dec 2005 09:46:30 +, Steve Holden wrote:
Paul Rubin wrote:
Steve Holden [EMAIL PROTECTED] writes:
The really interesting question your post raises, though, is Why do
you feel it's necessary to test to see whether a variable is a
Boolean?.
What's the point of having
that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values in list ? equality, it seems) ; did I
miss something ?
Regards,
Pierre
--
http
it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values in list ? equality, it seems) ; did I
miss something ?
issubclass(bool, int
for the obvious if type(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values in list ? equality, it seems
Pierre Quentel wrote:
In some program I was testing if a variable was a boolean, with this
test : if v in [True,False]
My script didn't work in some cases and I eventually found that for v =
0 the test returned True
This seems like a strange test. What is this code trying to do?
If
still
find it confusing that 0 in [True,False] returns True
From the docs: Python Library Reference, section 2.3.10.9:
Boolean values are the two constant objects False and True. They are
used to represent truth values (although other values can also be
considered false or true). In numeric contexts
(v) is bool, but I still
find it confusing that 0 in [True,False] returns True
By the way, I searched in the documentation what obj in list meant and
couldn't find a precise definition (does it test for equality or
identity with one of the values in list ? equality, it seems) ; did I
[EMAIL PROTECTED] wrote:
but seriously, unless you're writing an introspection tool, testing for
bool is pretty silly. just use if v or if not v, and leave the rest to
Python.
The OP's code(and his work around) doesn't look like he is testing for
boolean
which of course explains why
Fredrik Lundh wrote:
[EMAIL PROTECTED] wrote:
but seriously, unless you're writing an introspection tool, testing for
bool is pretty silly. just use if v or if not v, and leave the rest
to
Python.
The OP's code(and his work around) doesn't look like he is testing for
60 matches
Mail list logo
