1

I started using Python in 2001. I loved the simplicity of the language, but one feature that annoyed the heck out of me was the / operator, which would bite me in subtle places like

def mean(seq):
    """
    Return the arithmetic mean of a list
    (unless it just happens to contain all ints)
    """
    return sum(seq) / len(seq)

Fortunately, PEP 238 had already been written, and as soon as I found about the new from __future__ import division statement, I started religiously adding it to every .py file I wrote.

But here it is nearly 9 years later and I still frequently see Python code samples that use / for integer division. Is // not a widely-known feature? Or is there actually a reason to prefer the old way?

Community
  • 1
  • 1
dan04
  • 87,747
  • 23
  • 163
  • 198

3 Answers3

8

I think // for truncation is reasonably well known, but people are reluctant to "import from the future" in every module they write.

The classic approach (using float(sum(seq)) and so on to get a float result, int(...) to truncate an otherwise-float division) is the one you'd use in C++ (and with slightly different syntax in C, Java, Fortran, ...), as well as "natively" in every Python release through 2.7 included, so it's hardly surprising if a lot of people are very used to, and comfortable with, said "classic approach".

When Python 3 becomes more widespread and widely used than Python 2, I expect things to change.

Alex Martelli
  • 854,459
  • 170
  • 1,222
  • 1,395
2

You can change the behaviour of / for the whole interpreter if you prefer, so it's not necessary to import from future in every module

$ python -c "print 1/2"
0
$ python -Qwarn -c "print 1/2"
-c:1: DeprecationWarning: classic int division
0
$ python -Qnew -c "print 1/2"
0.5
John La Rooy
  • 295,403
  • 53
  • 369
  • 502
  • 4
    If you are writing code to be run by others, how do you mandate that they will run it with your preferred options? Looks like one of those "works for me on my machine" "solutions". – John Machin Aug 20 '10 at 06:37
  • 3
    @John, I guess on windows you'd use a .bat to run python with the correct options. In unix/linux you could add the options to the shebang line. Mostly though the `-Qwarn` is useful to find places you can upgrade from `/` to `//` without breaking anything – John La Rooy Aug 20 '10 at 07:01
  • 2
    I'd rather make the code just work properly independently of command line options. Options aren't much use when one is distributing packages/modules. – John Machin Aug 20 '10 at 09:22
  • I tried compiling the Python interpreter with hard-coded `-Qnew`, but it broke too many things. The `help()` function being one of them. – dan04 Aug 20 '10 at 13:16
1

To me it's always made sense that dividing using ints gives and int result in a language that doesn't normally do on the fly type conversions.

neil
  • 3,387
  • 1
  • 14
  • 11
  • I agree. Operators do different things for different types already. Think of + for addition / concatenation. – thieger Aug 20 '10 at 10:45
  • 3
    I disagree. Imagine if `math.sqrt(2)` returned 1 instead of 1.4142135623730951. In Python 2.1, `int` is a perfect substitute for `float` in all cases *except* division. – dan04 Aug 20 '10 at 13:15
  • @dan04: It's too bad more languages can't infer the types of operators to use based upon what's being done with the results. If f1-f2 are floats and d1 is a double, and one is computing `f2=f1+0.1;` it would make sense to convert 0.1 to float and perform the addition using `float`, but if one is computing `d1=f1+f2;` it would make more sense to convert the operands to double and then do the computation. Having operators should yield the same result type as their operands was easy to implement, but is IMHO ugly and prone to causing bugs. – supercat Nov 13 '13 at 21:20