Hi all,
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
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 of the values in list ? equality, it seems) ; did I
miss something ?
Regards,
Pierre
Dec 12 '05
59  4516 
Op 2005-12-14, Grant Edwards schreef <gr****@visi.com>: On 2005-12-14, bo****@gmail.com <bo****@gmail.com> 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 know -- homey don't play 'dat.
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 application False and True
(or Registered and UnRegistered if you prefer) are perfectly valid
values too. They are not "exception" cases that need to be
handled.
--
Antoon Pardon
On 2005-12-14, Antoon Pardon <ap*****@forel.vub.ac.be> 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 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 application False and True
(or Registered and UnRegistered if you prefer) are perfectly
valid values too. They are not "exception" cases that need to
be handled.
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
type it is. It's just a float.
--
Grant Edwards grante Yow! .. Do you like
at "TENDER VITTLES?"?
visi.com bo****@gmail.com 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 different form testing set membership. So what I did, was just
> bringing two disjoint sets togther and working with a variable from
> that union. This is all in all a rather simple mathematical idea.
> And I don't see why I should put certain information into a seperate
> variable. It makes as much sense as working with numbers and using
> a seperate variable to store whether a particular number is postive,
> even or has some other characteristic. You don't seperate information
> you can easily acquire from the variable itself. So why should I
> seperate this information that is aquired just as easily?
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 ? Or return NaN instead of raising exception for numeric
functions ?
Having a value to indicate "no value" is, of course, perfectly
reasonable. However, you then test *for that value*; you don't test
the type of the value to see if it's of the right type.
Once you get beyond the variable either having a valid value or not,
it's really time to consider a different approach. As has been
indicated, using two variables is ba well-respected method of doing
this. Another alternative (on the spur of the moment - I have no idea
how well this will really work) is a value-carrying "invalid value":
# untested code:
class Invalid:
state = 'unknown'
....
if self.count is Invalid:
if self.count.state == 'unregistered':
# Register self.
elif self.count.state == 'registered':
# Whatever
else:
# Deal with self.count outstanding requests
Hmm. I'm not sure I like this...
<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Mike Meyer wrote: bo****@gmail.com 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 different form testing set membership. So what I did, was just
> bringing two disjoint sets togther and working with a variable from
> that union. This is all in all a rather simple mathematical idea.
> And I don't see why I should put certain information into a seperate
> variable. It makes as much sense as working with numbers and using
> a seperate variable to store whether a particular number is postive,
> even or has some other characteristic. You don't seperate information
> you can easily acquire from the variable itself. So why should I
> seperate this information that is aquired just as easily?
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 ? Or return NaN instead of raising exception for numeric
functions ?
Having a value to indicate "no value" is, of course, perfectly
reasonable. However, you then test *for that value*; you don't test
the type of the value to see if it's of the right type.
Once you get beyond the variable either having a valid value or not,
it's really time to consider a different approach. As has been
indicated, using two variables is ba well-respected method of doing
this. Another alternative (on the spur of the moment - I have no idea
how well this will really work) is a value-carrying "invalid value":
# untested code:
class Invalid:
state = 'unknown'
...
if self.count is Invalid:
if self.count.state == 'unregistered':
# Register self.
elif self.count.state == 'registered':
# Whatever
else:
# Deal with self.count outstanding requests
Hmm. I'm not sure I like this...
He doesn't need to test the type, in this case.
if self.count is False:
elif self.count is True:
else:
The alternative suggested :
if self.state is False:
elif self.state is True:
else: deal with self.count
I don't see much difference. He can also use a better name to represent
True/False.
Registered=True
UnRegistered=False
Op 2005-12-14, Grant Edwards schreef <gr****@visi.com>: On 2005-12-14, Antoon Pardon <ap*****@forel.vub.ac.be> 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 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 application False and True
(or Registered and UnRegistered if you prefer) are perfectly
valid values too. They are not "exception" cases that need to
be handled.
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
type it is. It's just a float.
Do you find that difference so important? As far as I understand
the gtk identifiers are always positive integers. So I could
have coded as follows:
UnConnected = (-1, -2)
Registered, UnRegistered = UnConnected
...
if self.cb_src in UnConnected:
Now all values are integers and I no longer treat an object different
depending on type but on value. However conceptually nothing changed.
My code branches depending on set membership of this attribute.
Could you explain why it should make a (big) difference between
these two approaches?
--
Antoon Pardon
Antoon Pardon wrote: Op 2005-12-14, Grant Edwards schreef <gr****@visi.com>: On 2005-12-14, Antoon Pardon <ap*****@forel.vub.ac.be> 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 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 application False and True
(or Registered and UnRegistered if you prefer) are perfectly
valid values too. They are not "exception" cases that need to
be handled.
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
type it is. It's just a float.
Do you find that difference so important? As far as I understand
the gtk identifiers are always positive integers. So I could
have coded as follows:
UnConnected = (-1, -2)
Registered, UnRegistered = UnConnected
...
if self.cb_src in UnConnected:
Now all values are integers and I no longer treat an object different
depending on type but on value. However conceptually nothing changed.
My code branches depending on set membership of this attribute.
Could you explain why it should make a (big) difference between
these two approaches?
That is what I would do in C or similar language where a variable can
only be one type.
Op 2005-12-14, Mike Meyer schreef <mw*@mired.org>: bo****@gmail.com 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 different form testing set membership. So what I did, was just
> bringing two disjoint sets togther and working with a variable from
> that union. This is all in all a rather simple mathematical idea.
> And I don't see why I should put certain information into a seperate
> variable. It makes as much sense as working with numbers and using
> a seperate variable to store whether a particular number is postive,
> even or has some other characteristic. You don't seperate information
> you can easily acquire from the variable itself. So why should I
> seperate this information that is aquired just as easily?
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 ? Or return NaN instead of raising exception for numeric
functions ?
Having a value to indicate "no value" is, of course, perfectly
reasonable. However, you then test *for that value*; you don't test
the type of the value to see if it's of the right type.
Once you get beyond the variable either having a valid value or not,
it's really time to consider a different approach.
How do you feel about testing for set membership? I can have a set
with values to be treated differently than values not in the set.
Do you consider that an acceptable approach?
--
Antoon Pardon
On 2005-12-15, Antoon Pardon <ap*****@forel.vub.ac.be> 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 application False and True
(or Registered and UnRegistered if you prefer) are perfectly
valid values too. They are not "exception" cases that need to
be handled.
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
type it is. It's just a float.
Do you find that difference so important?
Possibly. In my case, a float is always a float. You can
always do the same set of operations on it.
As far as I understand
the gtk identifiers are always positive integers. So I could
have coded as follows:
UnConnected = (-1, -2)
Registered, UnRegistered = UnConnected
In your case, there isn't a single set of operations that work
regardles of the value. You have to _check_ the value in order
to decide what operations are allowed on that value. I'm not
saying the latter is "evil" but I think the distinction is
important.
...
if self.cb_src in UnConnected:
Now all values are integers and I no longer treat an object different
depending on type but on value. However conceptually nothing changed.
My code branches depending on set membership of this attribute.
Could you explain why it should make a (big) difference between
these two approaches?
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 the same
"operations" that a "real" GTK identifier does. They are two
different types.
--
Grant Edwards grante Yow! Hey, wait a
at minute!! I want a
visi.com divorce!!... you're not
Clint Eastwood!!
Op 2005-12-15, Grant Edwards schreef <gr****@visi.com>: On 2005-12-15, Antoon Pardon <ap*****@forel.vub.ac.be> 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
type it is. It's just a float.
Do you find that difference so important?
Possibly. In my case, a float is always a float. You can
always do the same set of operations on it.
As far as I understand
the gtk identifiers are always positive integers. So I could
have coded as follows:
UnConnected = (-1, -2)
Registered, UnRegistered = UnConnected
In your case, there isn't a single set of operations that work
regardles of the value. You have to _check_ the value in order
to decide what operations are allowed on that value. I'm not
saying the latter is "evil" but I think the distinction is
important.
...
if self.cb_src in UnConnected:
Now all values are integers and I no longer treat an object different
depending on type but on value. However conceptually nothing changed.
My code branches depending on set membership of this attribute.
Could you explain why it should make a (big) difference between
these two approaches?
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 the same
"operations" that a "real" GTK identifier does. They are two
different types.
I think the disctinction you are making is based on which level
you look at things. For you floats are something you use, you
see NaN as just a floats because the details of implementation
have been abstracted out for you.
But look at it from the level of someone who has to implement
floating point numbers. He can't just take two floats and put
them into his general add_float algorithm. If he did that
the result of working with a NaN could result in a regular
number. So he has to test for special values like NaN is
his 'code' too.
Of course we tend to forget this because in this case the
abstraction is usually done at the hardware level. But
I don't think that is such an important disctinction here.
--
Antoon Pardon
On 2005-12-16, Antoon Pardon <ap*****@forel.vub.ac.be> 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 the same
"operations" that a "real" GTK identifier does. They are two
different types.
I think the disctinction you are making is based on which level
you look at things.
Of course. I was looking at things from a Python point of view
since this is c.l.p.
For you floats are something you use, you see NaN as just a
floats because the details of implementation have been
abstracted out for you.
That goes without saying for anything in computer science or
electronics: it's all just quantum physics whose details of
implimentation have been abstracted out for me.
But look at it from the level of someone who has to implement
floating point numbers. He can't just take two floats and put
them into his general add_float algorithm. If he did that the
result of working with a NaN could result in a regular number.
So he has to test for special values like NaN is his 'code'
too.
Of course we tend to forget this because in this case the
abstraction is usually done at the hardware level. But I don't
think that is such an important disctinction here.
The distinction is in regards to readability and
maintainability of _Python_ code. This is comp.lang.python.
--
Grant Edwards grante Yow! does your DRESSING
at ROOM have enough ASPARAGUS?
visi.com This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Sylvain Thenault |
last post by:
Hi there !
Can someone explain me the following behaviour ?
>>> l =
>>> 0 in (l is False)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: iterable argument...
|
by: Bradley Plett |
last post by:
I have what should be a trivial problem. I am using XMLSerializer to
serialize an object. It serializes boolean values as "True" and
"False". I then want to use an XSLT on this XML, and I want...
|
by: Carpe Diem |
last post by:
Hello I have an aspx page that loses Session("user") value after a few
minutes even after I set
<sessionState mode="InProc" cookieless="false" timeout="300"> in web.config
and wrote
function...
|
by: Ben |
last post by:
Hi;
I use ain asp.net the CreateUserWizard control for new users. When it's
done, i want to redirect them to another page (modifyprofile.aspx). This
works with the code below.
My question is:...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| | |
