A modest PEP0238 suggestion

Tim Peters tim.one at home.com
Wed Jul 25 11:43:24 CEST 2001

[Stephen Horne]
> How would you feel if you found out that installing your new wiz-bang
> application suddenly meant your bread-and-butter application broke.
> That is what can happen - someone gets a new application from a
> different supplier, updates their Python to use it and *BANG* - the
> existing app breaks.

How do you intend to package your apps?  On Windows, Python ships with the
Microsoft C runtime libraries it was tested with, to be sure that broken C
libraries on the user's machine can't hurt it.  This is common practice for
major Windows apps of all kinds -- it's basic defensive practice.

Similarly, you've got mostly yourself to blame if you don't ship your
bread-and-butter Python apps with the versions of Python they were tested
with.  It's not like you can *expect* your customers to have Python already
installed:  you have to ship *some* version of Python with your apps.  It's
little additional work from there to isolate your version of Python from
whatever other versions they may already have installed  -- or may ever
install in the future.

Dead serious apps don't take chances, and there are no restrictions in the
Python license on redistributing it with your apps.  If you don't isolate
your app from user whims, there's no guarantee it will continue to work even
if they install a single bugfix to a shared Python.  I don't know which OS
you're targeting, but it doesn't sound like you've thought about the big
picture here, be it Linux or Windows.  The more important the app, the more
important to cover your butt, and even pure bugfixes can break code that
relied on accidents.

test-what-you-ship-and-ship-what-you-test-ly y'rs  - tim

More information about the Python-list mailing list