A modest PEP0238 suggestion

[Tim Peters]

[TIm]
> I see I have 12 copies of the Microsoft C runtime library on my
> Win98 box at the moment, and for the same reason:  serious Windows app
> developers are careful to isolate themselves from C runtime changes too.

[James Logajan]
> ...
> Well I see your problem already: you are developing on the wrong OS. It
> makes your thinking fuzzy.

Yes, but in such a warm and helpful way <wink>.

> Some of us don't have Solaris, Linux, BSDI, AIX, Mac OS, etc. platforms
> all sitting on our desk (that would be some desk!) to build complete
> runtime interpreters.

Do you think PythonLabs does?  If volunteers don't show up to test alpha and
beta versions of Python on their particular Platforms from Mars, there's no
particularly good reason to believe that a new release of Python will even
*compile* on oodles of platforms.  Things have improved a lot since we moved
development to SourceForge, but it's still the case that, every release, we
get a rash of "but it doesn't even compile on WackoWix 8.3 running Qljx!"
reports soon after the final release.  Study SourceForge and weep.

> So we ship only source and hope the target users read the instructions
> on which version of Python we think we've validated our code on.

I expect that's the best you *can* do, too, if you're targeting every Python
platform.  But if you have a particular financial or professional interest
in, say, making sure your app runs forever under Mandrake and Red Hat, I
still say you're nuts if you don't exploit the easy alternative of shipping
platform-specific Python binaries for those platforms with your app.

Without that, you're still going to be a lot more portable than raw C code
(as portable as 10 years of development have been able to make the C code in
Python), but there are no reliable all-platform guarantees even for a fixed
Python release.

whether-unix-zoo-or-ms-tarpit-there's-danger-on-all-sides-ly y'rs  - tim