Given the sample code:

  for i in range(len([1, 2]) / 2): pass

  print 2 / 3

2to3 tells no files need to be modified after running it over this code,
but range doesn't accept float values and the print result will differ.
Would it be too expensive for 2to3 to suggest changing '/' to '//' ?

My gut feeling is that the number of cases where both operands are
written as literals is exceedingly small when compared to the number of
cases where one or both is an identifier. Since 2to3 doesn't support
type inference, we'd miss the relevant, interesting cases. However, if
you're interested in implementing a fix_literal_division fixer module
that would catch these cases, I'd be happy to advise on such a thing :)

If I were to add such fixer, should I wait for changes coming by gsoc
projects ? I did a quick pass through 2to3 code a while ago, but I'm
very far from understanding it in a good manner so I'm not sure if I
should starting doing that now because it looks like a GSoC project is
planning to change how 2to3 works.

I say do it before the GSoC projects complete. Those projects will take
months, and we can't stop development for that long.

+1 for going ahead and writing a fixer.

I thought the right way to handle this is with a -3 option.  That's the
only way to reliably detect the intended meaning of / and its change in
meaning in 3.0.

I concur with Raymond. There isn't yet a "-3" warning for class
division, though. I suppose the compiler could emit one when "/" is used
without from __future__ import division. That's another issue, though.