[Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)

[C. Titus Brown]

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 at msu.edu