Alan: 2^(1/2) Kirby: Also pow(2, 0.5) in Python.
Alan: Gee, I wonder if pow(2, (1/2)) also works in Python? Kirby: It does if you remember integer division in earlier versions, such that one needed: from __future__ import division or, simply made it 1./2 or 1/2. or something, to force a floating point answer. In 3.x, division is natively floating, with // to force an integer output. [ EDITOR'S NOTE: not quite right, may be floating type output with integer value ] This is Python 3.1, right out of the box: >>> pow(2, 1/2) 1.4142135623730951 Alan: That reminds me of FORTRAN http://en.wikipedia.org/wiki/Fortran_language_features#Implicit_and_explicit_typing "Unless specified otherwise, all variables starting with letters I, J, K, L, M and N are default INTEGER, and all others are default REAL; other data types must be explicitly declared. This is known as implicit typing and is a heritage of early FORTRAN days." Kirby: I think the original intent was something like "closure" i.e. int / int should give int, whereas float / float or float / int or int / float should coerce float answer, and that is how it was done. However it was later realized, by Guido and others, that in source code, when you see a / b, you really have no way of knowing what's going through there, i.e. a and b might name anything, so it gets hard to debug if the behavior is so dependent on 1 versus 3 use cases. Better to just have a consistent float output, no matter what. Then use // if you want to force an integer value output, even if you input floats to get floats back: >>> 1.//2. 0.0 >>> 1/2 0.5 >>> 3.//2. 1.0 It's quite basic to a language, how it deals with division, so Guido had to devise a scheme that would let the snake "shed its skin". Already, the brand name (Python) was in his favor, as that's what Pythons do (shed skin). A lot of basic changes piled up, including a more complete move to a Unicode basis for source files. If you're going to break backward compatibility, might as well do a lot of breaking all at once. As of this writing, we're on the other end of it, having made the leap from 2.x to 3.x. The backward incompatibility gap has been crossed. However, a number of important libraries and other assets still need to bring up the rear, so a new PEP (Python Enhancement Proposal) has been accepted, to freeze Python for awhile, in terms of its core syntax and semantics. Give the library people some breathing room. This seems a good plan. [ original context: http://groups.yahoo.com/group/synergeo/ ] -- http://mail.python.org/mailman/listinfo/python-list
