Backwards Compatibility of Python versions

[Paul Rubin]

Jonathan Hogg <jonathan at onegoodidea.com> writes:
> > The program I'm hacking right now actually needs exact rational
> > division, but that's another story.  The issue is there's no way to
> > use integer division that works in both 2.1 and 3.0, without using
> > something like divmod that would shock the unwary.
> 
> I'm sorry, the "unwary"? I presume by this you mean that your user base
> contributes to your code, that you aren't the only programmer on the
> project? Are the other coders having difficulty with reading or writing
> 1.5.2 forward compatible code?

By the unwary maybe I should have said the unconverted.  For example,
I sent a Python script last night to a Lisp user, that very nicely
solves in Python something that the Lisp people were going on about
how Lisp was so great for.  The intention was that the Lisper would
see the clean infix expressions, the absence of parentheses, the
natural expression of the algorithm, and say "wow, neat, I think I'll
start programming in Python too".  But if instead of a/b they have
to see divmod(a,b)[0], they'll think it's even worse than parentheses.

> The easy way for you to tell is to make two versions of your code available,
> one written for 1.5.2 and one optimised for 2.1 upwards (where they may be
> exactly the same version - I'm not suggesting you do any more work). You'll
> be able to gauge from downloads/sales/however your users obtain your work,
> which version they have.

I have no way to know from downloads how many copies of the program
are spread around by other means.  It's free software, so there's no
sales.  It's the exact same problem as knowing how many users are
running Python 1.5.2.  Downloads from python.org are probably
outnumbered by Red Hat cd's by a fair margin.

> At the moment, this honestly looks like a storm in a teacup to me. I'm sure
> you can put a small disclaimer on your program saying "I cannot guarantee
> this program will work in some unknown future time on an as yet unknown
> version of the Python interpreter."

I could also save myself a lot of programming by writing a small
disclaimer saying that the program doesn't work on the present
interpreter either, but the idea is to write code that works.  The
next best thing is to write code that fails immediately and prints an
error message.  The last thing I want is code that appears to work but
generates the wrong answers, which is what the division change can cause.

I guess if I don't want to deal with making separate 2.1 and post-2.1
versions, I can just put in an initialization check that stops the
program from working in 3.0 and higher, and says to download a new
version of the program (much smaller than downloading a new
interpreter) which would presumably exist by the time 3.0 became
widespread.  Maybe I'll end up doing that.