Python less error-prone than Java

[nikie]

Christoph Zwerschke wrote:

> nikie wrote:
>  > Let's look at two different examples: Consider the following C# code:
>  >
>  > static decimal test() {
>  >    decimal x = 10001;
>  >    x /= 100;
>  >    x -= 100;
>  >    return x;
>  >
>  > It returns "0.01", as you would expect it.
>
> Yes, I would expect that because I have defined x as decimal, not int.
>
>  > Now, consider the python equivalent:
>  >
>  > def test():
>  >     x = 10001
>  >     x /= 100
>  >     x -= 100
>  >     return x
>
> No, that's not the Python equivalent. The equivalent of the line
>
> decimal x = 10001
>
> in Python would be
>
> x = 10001.0
>
> or even:
>
> from decimal import Decimal
> x = Decimal(10001)

Hm, then I probably didn't get your original point: I thought your
argument was that a dynamically typed language was "safer" because it
would choose the "right" type (in your example, an arbitrary-pecision
integer) automatically. As you can see from the above sample, it
sometimes picks the "wrong" type, too. Now you tell me that this
doesn't count, because I should have told Python what type to use. But
shouldn't that apply to the Java binary-search example, too? I mean,
you could have told Java to used a 64-bit or arbitrary-length integer
type instead of a 32-bit integer (which would actually be equivalent to
the Python code), so it would do the same thing as the Python binary
search implementation.

> ...
> By the way, the equivalent Python code to your C# program gives on my
> machine the very same result:
>  >>> x = 10001.0; x /= 100; x -= 100; print x
> 0.01

Try entering "x" in the interpreter, and read up about the difference
between str() and repr().

>
>  > Even if you used "from __future__ import division", it would actually
>  > return "0.010000000000005116", which, depending on the context, may
>  > still be an intolerable error.
>
> With from __future__ import division, I also get 0.01 printed. Anyway,
> if there are small discrepancies then these have nothing to do with
> Python but rather with the underlying floating-point hardware and C
> library, the way how you print the value and the fact that 0.01 can
> principally not be stored exactly as a float (nor as a C# decimal), only
> as a Python Decimal.

The is OT, but what makes you think a C# decimal can't store 0.01?

>  > I can even think of an example where C's (and Java's) bounded ints are
>  > the right choice, while Python's arbitraty-precision math isn't:
>  > Assume you get two 32-bit integers containing two time values (or
>  > values from an incremental encoder, or counter values). How do you
>  > find out how many timer ticks (or increments, or counts) have occured
>  > between those two values, and which one was earlier? In C, you can
>  > just write:
>  >
>  >    long Distance(long t1, long t0) { return t1-t0; }
>  >
>  > And all the wraparound cases will be handled correctly (assuming there
>  > have been less than 2^31 timer ticks between these two time values).
>  > "Distance" will return a positive value if t1 was measured after t0, a
>  > negative value otherwise, even if there's been a wraparound in
>  > between. Try the same in Python and tell me which version is simpler!
>
> First of all, the whole problem only arises because you are using a
> statically typed counter ;-) And it only is easy in C when your counter
> has 32 bits. But what about a 24 bit counter?

Easy, multiply it with 256 and it's a 32-bit counter ;-)
Fortunately, 24-bit-counters are quite rare. 16-bit or 32-bit counters
on the other hand are quite common, especially when you're working
close to the hardware (where C is at home). All I wanted to point out
is that bounded integers do have their advantages, because some people
in this thread apparently have never stumbled over them.