Schizoid Man wrote: > "Chris Angelico" <ros...@gmail.com> wrote in message > news:mailman.1289.1359801291.2939.python-l...@python.org... >> On Sat, Feb 2, 2013 at 9:27 PM, Schizoid Man <schiz_...@21stcentury.com> >> wrote: >>> The quantity s is input with the following line: s = input("Enter s: >>> ") >>> >>> To get rid of the compile error, I can cast this as a float: s = >>> float(input("Enter s: ")) >>> >>> However, then the result returned by the method is wrong. Why does this >>> error occur in version 3.3.0 but not in 2.7.3? Why is the result >>> incorrect >>> when s is cast as a float (the casting is not required in 2.7.3)? How is >>> Python dynamically typed if I need to cast (in version 3.3.0 at least) >>> to get rid of the compile error? >> >> Did you use input() or raw_input() in 2.7.3? If the former, you were >> actually doing this: >> >> s = eval(input("Enter s: ")) >> >> That's extremely dangerous and inadvisable, so it's better to go with >> 3.3 or the raw_input function. > > Thanks for the reply. You're right - even in 2.7.3 if I toggle between > float(input(x)) and input(x), the result of the calculation changes.
Highly unlikely. I'd say impossible, unless you type a different value for x of course. By the time the input() function returns, the result is already a float. Wrapping it in float() again cannot possibly change the value. If you have found a value that does change, please tell us what it is. The only examples I can think of that will behave that way involve NANs and INFs. If you don't know what they are, don't worry about it, and forget I mentioned them. For regular floating point values, I can't think of any possible way that float(input(x)) and input(x) could give different results. > What does the float cast do exactly? float(x) converts x into a float. - if x is already a float, it leaves it unchanged; - if x is a string, it converts it to the nearest possible float; - if x is some other numeric value (e.g. int, Decimal or Fraction, but not complex) it converts it to the nearest possible float. >> Passing it through float() is, most likely, the right way to do this. >> But what do you mean by "the result... is wrong"? That's the bit to >> look into. > > Scratch that, I'm not sure which result is right now, so need to look at > the full calculations in details. What would be the difference between > raw_input() and float(input())? In Python 2.x, raw_input returns a string. To turn it into a float, you need to use float(raw_input()). float(input()) is a waste of time. The dangerous part happens in the call to input(): a malicious user could type a Python command, and run arbitrary code; or they could type something like "10**100**100" and lock up your computer. Calling float *after* the call to input doesn't do anything. In Python 3.x, raw_input is gone, but float(input()) is safe -- it is exactly equivalent to float(raw_input()) in Python 2.x. One other difference between Python 2.7 and 3.3 is that they sometimes display floats slightly differently. Sometimes 3.3 will show more decimal places: [steve@ando ~]$ python2.7 -c "x = 1.0/33; print (x+x+x)" 0.0909090909091 [steve@ando ~]$ python3.3 -c "x = 1.0/33; print (x+x+x)" 0.09090909090909091 but you can be sure that they are the same value, it is just a difference in the default display of floats: [steve@ando ~]$ python2.7 -c "x = 1.0/33; print (x+x+x).hex()" 0x1.745d1745d1746p-4 [steve@ando ~]$ python3.3 -c "x = 1.0/33; print((x+x+x).hex())" 0x1.745d1745d1746p-4 -- Steven -- http://mail.python.org/mailman/listinfo/python-list
