PEP0238 lament

[Duncan Grisby]

In article <mailman.995930743.17137.python-list at python.org>,
 Paul Prescod  <paulp at ActiveState.com> wrote:

>All backwards compatibility issues are a matter of patience. Do you
>think that anybody would complain if something that was deprecated
>between Python 1.4 and Python 1.5 was formally removed now? Maybe it
>will take ten years for us to provide a migration path to new-style
>division. That is not an argument for putting of the beginning of that
>process. If we had started two years ago we would be two years closer to
>being able to fix the problem finally. It is Guido's job to take the
>long view.

The thing about this change is that it is different from other changes
there have been (that I'm aware of), in that it changes a fundamental
part of the language semantics. Switching from the current / behaviour
to the new proposal is not the same as _removing_ a feature -- it is
_changing_ a feature. That is far more insidious.

I agree, by the way, that if we were discussing a new language, it
would be sensible to use / for fractional division and // for integer
division (and just as sensible to do the reverse). I'm amazed at the
passion behind people arguing about what, to me, is an arbitrary
language choice. But that isn't the issue here. We aren't designing a
new language, we're modifying an existing one.

I return to my question. Suppose Python 2.2 is released with this
__future__ division. Now suppose I must maintain some code which can
run on Python 2.0, 2.1 and 2.2, which needs integer division. What am
I to do?  I can continue to use /, safe in the knowledge that I
haven't done the __future__ import, but that doesn't take the
long-term view -- it would be similarly foolish to write new code
which uses "yield" as an identifier, since I know that it's going to
break later.

So what can I do?  I can't even do something ugly like

  if sys.hexversion > 0x2000200:
      c = a // b
  else:
      c = a / b

since the a // b gives a syntax error.

The only option I can think of is to avoid integer division
altogether, and implement it myself by other means. That just uglifies
everything (and makes it slower, but that's not what bothers me most).

In an ideal world, everyone would upgrade to new Python versions the
moment they are released. The world just isn't like that, and people
providing Python programs and libraries _have_ to support multiple
Python versions.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --