A single installer could support both 32-bit on 10.4 and 64-bit on 10.5, but I don't think that's very useful because there are changes in the low-level unix API's that could result in different behaviour of a 32-bit and 64-bit script on the same system. In general 10.5 has much saner Unix API's than earlier releases.
I don't get that. Why would the scripts behave differently on 10.5 depending on whether the Python interpreter is 32-bit or 64-bit? Surely, the Unix API does the same thing, whether invoked from 32-bit code, or 64-bit code, no?
I still wish there were 10.3+ installers that also include 64-bit code. I don't get it why that can't be technically possible.
The problem with 10.3 support is that we need volunteers to actually investigate and fix issues that only occur on 10.3 systems. I cannot be that volunteer because I no longer have access to systems that are capable of running 10.3.
I don't think it is necessary to actually test whether the binaries work on 10.3; I don't test the Windows installers on Windows 2000, either. For me, it's good enough if we believe that the installer "should" work on 10.3. Then, if somebody reports a problem, we can still consider what to do. If there are no reports, it either means there are no problems, or nobody uses it, or nobody bothers reporting the problems.
That said, the difference between a binary capable of running on 10.4+ and one running 10.3+ is minimal. I introduced weak-linking for a number of symbols that are not present on 10.3.9 in the 2.5 timeframe and that could should continue to work in the future. I won't notice when someone introduces additional calls to functions not available on 10.3 though.
Sounds good to me! Regards, Martin