Backwards Compatibility of Python versions

[Manoj Plakal]

Paul Rubin wrote:

> The claim was that "from __future__ import division" and using //
> stops your old code from breaking when 3.0 comes out, which fits your
> definition of backward compatibility.  I pointed out that it only
> works for 2.2 and later.  It doesn't provide backwards compatibility
> to the versions of Python that most people actually use today.
>

 > [snip]

>  
> But that means I can't say "from __future__ import division", since
> only 2.2 and later support that.  And if I don't say that, then my
> scripts will break in 3.0.  How many times do I have to explain this?
> 


          Correct me if I'm wrong but I think we've all been
          warned that the next major release of Python (3.0,3000,...)
          could break backward compatibility with old versions.

          So if you're distributing Python code, it looks
          like you have some choices:
              - Require use of Python <= 2.1, no matter
                what the latest and greatest version of
                Python provides (perhaps bundle the interpreter
                with your software if people don't want to keep
                an extra copy of Python to run your stuff)

              - Require Python <= 2.1 now, but eventually
                migrate your users to 2.2 or 3.0 by releasing
                newer versions of your software

              - Require Python >= 2.2 now, and hopefully
                use the from future mechanism to avoid
                the above headaches.

          Also, I'm curious, why does your code depend
          so critically on integer division? There
          are some not-so-ugly approximations to
          quotient and division that will work on
          all versions of Python (I believe):
               int(x/y) for integer division
               float(x)/y for "true" division
          There may be problems with rounding
          and negative numbers and what not, but I
          think these will work for the majority of
          positive number calculations you want to do.
          It's the similar situation in C where
          I need to use a cast to do "true" division instead
          of integer division. BTW, I am not
          interested in starting another division
          thread, so if you don't like this
          solution, please ignore it :)

          Manoj