[Python-Dev] bsddb alternative (was Re: [issue3769] Deprecate bsddb for removal in 3.0)
C. Titus Brown
ctb at msu.edu
Thu Sep 4 17:10:50 CEST 2008
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
- 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!
C. Titus Brown, ctb at msu.edu
More information about the Python-Dev