On Thu, Sep 04, 2008 at 11:01:35AM -0400, Tony Nelson wrote: -> At 7:37 AM -0700 9/4/08, C. Titus Brown wrote: -> >On Thu, Sep 04, 2008 at 10:29:10AM -0400, Tony Nelson wrote: -> ... -> >-> Shipping an application to end users is a different problem. Such packages -> >-> should include a private copy of Python as well as of any dependent -> >-> libraries, as tested. -> > -> >Why? On Mac OS X, for example, Python comes pre-installed -- not sure -> >if it comes with Tk yet, but the next version probably will. On Windows -> >there's a handy few-click installer that installs Tk. Is there some -> >reason why I shouldn't be relying on those distributions?? -> -> Yes. An application is tested with one version of Python and one version -> of its libraries. When MOSX updates Python or some other library, you are -> relying on their testing of your application. Unless you are Adobe or -> similarly large they didn't do that testing. Perhaps you have noticed the -> threads about installing a new Python release over the Python that came -> with an OS, and how bad an idea that is? This is the same issue, from the -> other side. I have to say I've never had problems with a stock install of Python on either Mac OS X or Windows (shockingly enough :). I think this is good advice for applications that rely on external libraries, but I just don't see any problems with relying on Python 2.5 to contain all the things that normally come with Python 2.5. It seems like you're pushing a pretty sharp dichotomy (trichotomy?) -- - Python library/core developers should compile it all. - Python app developers can rely on what they install from binaries themselves, but not rely on it to be present on anyone else's machine or OS. - End users should be given a complete clean install of Python in a different location for each application they're using, even if those applications depend only on the stdlib. This seems surprisingly complicated to me (and unnecessary, in my limited experience) -- but it does validate my decade-old decision to avoid writing end-user applications in Python, sadly enough. It ends up being less work to distribute and support a C/C++ app on Windows and Mac OS X, for crikey's sake! --t -- C. Titus Brown, ctb@msu.edu