Trent Mick trentm at
Wed Jul 4 19:07:18 CEST 2007

Frank Swarbrick wrote:
> Why might one choose to use ActivePython instead of using the free CPython?

Expanding on what Alex already said, there are a few reasons:

1. On Windows, ActivePython also includes the PyWin32 [1] extensions 
which otherwise you'd have to install separately over a install.

2. ActivePython includes ready-to-install packages for more platforms 
(some of which the distros also cover, of course):
     * Windows/x86 and Windows/x64,
     * Mac OS X (Universal build),
     * Linux/x86 and Linux/x86_64,
     * Solaris SPARC and x86,
     * HP-UX, and
     * AIX.
For some of these platforms (e.g. Linux), a fair amount of work has been 
done to ensure you can use all of the core extensions (e.g. Tkinter, 
bsddb, bzip2, etc.) out of the box without running into dependency 
issues. ActivePython's installer on the Un*x platforms also makes it 
easy to install either in a shared location or in a user-specific location.

3. ActivePython includes a number of extra documentation sets that may 
prove useful to some. E.g. "Dive Into Python", a non-programmer's 
tutorial for Python, the Python HOWTOs, a snapshot of the Python PEPs, 
the Python FAQs, back copies of Andrew Kuchling's excellent "What's New 
in Python"

Some sometimes mentioned, but untrue reasons to avoid ActivePython:

- It doesn't include OpenSSL bindings.
   As of ActivePython, full SSL bindings are included.

- It isn't free.
   See my answer to Steve, below.

- It isn't compatible with's Python distro.
   It is. If there is a case where this isn't the case, it is a serious bug.

Some more details here:

To answer some questions from others on this thread:

tleeuwenburg wrote:
 > Well, Komodo is a nice enough IDE, so you might choose to use
 > ActivePython for integration reasons, and maybe it's a little easier
 > on Windows.
 > However, I would have thought that if you were planning to distribute
 > an application, you would want to choose CPython for maximum
 > interoperability with external packages.

Note that Komodo in no way, "prefers" ActivePython over a 
installation. One of the primary requirements of ActivePython is to 
fully binary compatible with a build of the same version -- 
if it isn't, it is a serious bug. As well, with Komodo we aren't *at 
all* interested in locking people in to our language distros. (BTW: I 
also work on Komodo.)

 > The ActiveState web page doesn't
 > really talk about their reasons very much.

As to reasons for ActivePython: ActiveState believes in the dynamic 
languages (all of the developers here are very passionate about that) 
and we are both happy to and view it as in our best interests to do what 
we can to ensure that the dynamic language communities are vibrant and 
competitive with the more corporate-backed languages and technologies.

Of course, it isn't pure altruism, but more of a symbiosis. ActiveState 
provides for-pay contracts for Perl, Python and Tcl distributions for 
things like specific support and builds (for example, some companies are 
happy to pay for the leg-work for an up-to-date Python installer for an 
old version of HP-UX that supports their C++ extensions).

Generally, any patches that we've worked on for these kinds of things 
are provided back to the language cores so that everyone benefits. As 
well, these contracts allow us to maintain a large number of build and 
test machines for the for-pay and free Active* distros -- and to buy 
food for developers such as myself.

Steve Holden wrote:
 > ...the last time I looked the ActivePython distribution
 > doesn't allow redistribution at all (i.e. it's not technically open
 > source).

Steve is correct that ActivePython isn't open source. It is free (as in 
beer), meaning that it is completely free for you to download, install 
and use on as many machines as you want.

As to redistribution: Yes, it is technically correct that you cannot 
fully redistribute ActivePython without our permission. However, 
ActivePython's license expressly *does* allow you to use the "freezing" 
utilities such as "py2exe" and "py2app" -- so you have no worries there. 
  For fully embedding Python in an application, in my experience [2] 
you'll want to be building your own Python anyway.

Python Tech Lead at ActiveState
also, a Komodo developer

[1] PyWin32 is primarily a set of extensions that provide Python 
bindings to much of the Windows API and to Windows COM. It also includes 
an editor/IDE called PythonWin. <>

[2] Komodo embeds its own Python build for doing a lot of the core 
logic. A custom Python build is generally necessary to avoid 
cross-talking between Komodo's Python and other possible Pythons on the 

Trent Mick
trentm at

More information about the Python-list mailing list