Python comparison problem - Could it be entity vs. value comparison?

[Steve Luke]

Hey all,

So I am starting to learn python and I ran into a weird occurrence. I had code which essentially does this:

    _count = 0
    def getFractionOfTotal(someValue):
        if _count is 0:
            return 0.0
        else:
            countF = float(_count)
            fraction = someValue / countF
            return fraction

I could run the code 5 or 6 times and the last time through it would give me a division by zero. For more details see below. My thought is that this looks like something I am familiar with in Java - String comparisons where you make an entity based comparison (ie str1 == str2) when that type of comparison isn't appropriate. Turns out 'is' is an entity based comparison in Python, so I changed the code to value based comparisons (in Python, == is value based if I understand correctly):

    _count = 0
    def getFractionOfTotal(someValue):
        if _count == 0:
            return 0.0
        else:
            countF = float(_count)
            fraction = someValue / countF
            return fraction

When I did that, the problem appears to have gone away. It sort of makes sense to me, in Python integers are Objects, maybe the 0 value is cached so initial tests with 'is' look ok, but then my no-ops cause enough memory to cycle that makes the cached value get flushed and now 0 isn't the same cached object that was assigned to _count and the 'is' comparison no longer works.

I just don't know if that is true or not, and I would like to get confirmation if anyone has any idea...

Some more background - I am actually testing other conditions, and those conditions make sure the _count never increments. When the count does increment I would never get a div by 0 error. This is a single threaded application - no chance of some other thread modifying countF or _count behind the scenes. I couldn't duplicate it by simply putting this code in a loop, but I could duplicate it quite easily by putting the application through 5 or 6 no-ops which have no effect on _count. More specifically, I am using IronPython2.4.

[Campbell Ritchie]

Don't understand the bit about incrementing count.

But about use of the is keyword: you would appear to be correct. It would appear that your count is an actual object rather than a primitive. Therefore using == will test the values are the same whilst using is tests whether the two are the same object. You will need to find whether multiple 0s are cached rather like wrapper classes in Java. In which case you might find you are checking object identity rather than value equivalence, rather like using the == operator and equals() method on Java objects.

Remember these features vary from language to language, so you need to find the Python specifications somewhere.

[Steve Luke]

Campbell Ritchie wrote:Don't understand the bit about incrementing count.

Yeah, it isn't really germane to the topic - essentially I am doing other work, but _count remains 0.

But about use of the is keyword: you would appear to be correct. It would appear that your count is an actual object rather than a primitive. Therefore using == will test the values are the same whilst using is tests whether the two are the same object. You will need to find whether multiple 0s are cached rather like wrapper classes in Java. In which case you might find you are checking object identity rather than value equivalence, rather like using the == operator and equals() method on Java objects.

Remember these features vary from language to language, so you need to find the Python specifications somewhere.

Thanks for the feedback. I tried to locate information about object caching but unfortunately there doesn't seem to be an actual Python Language Specification. The Python Language Reference is more of a syntax and structure reference, rather than a specification, and doesn't describe object caching, it just says that comparing numeric literals may be comparing the same object or may not. I guess this stresses the point that I should definitely not be using the is comparison.

[Campbell Ritchie]

Yes, that appears to be as far as we can go with this problem.