I am new to Python. I am supposed to launch an application and perform some tasks on the application from Python.
I found Python from python.org and ActivePython from activestate.com.
What is the difference between them? Which should I install?
ActiveState is an open source company which bundles Python with some additional packages and makes it available for variety of platforms. Sometimes they support platforms which the standard Python distrubution does not. For example AIX comes to my mind.
Many beginners to python on Windows have this doubt when they start with Python. ActiveState provides a bundle of Python executable with Python Windows Extensions and PEPS and Dive into Python ebook as package, so that you will have a good solution.
Technically there is not any difference between Python from activestate.com and from python.org if it available for download for your platform.
And yes, you can install Python 2.7.1 as it is latest supported version in 2.x series.
One key difference is that ActivePython comes with a binary package manager called PyPM that makes it easier to install packages like numpy, scipy and lxml.
ActiveState usually only provides the latest versions of their packages for free, if you need an older version for whatever reason you will have to sign up for one of their paid accounts. Python.org seems to have all their old versions available for download.
An important difference is that ActiveState Python is proprietary software and, if you put it in production, they can force you into subscription software fees and sue you if you don't pay. Their sales people have been tracking down heavier users and companies with more users and threatening them into unexpected payments.
Starting with Python 3.9, ActiveState has a new approach. Developers can create their own builds of Python 3.9 for free on the ActiveState Platform - and these builds are pure Open Source.
There still are proprietary limits - but these are based on how much an individual or organization uses the ActiveState Platform and not on the licensing of the software.
Full disclosure: I work for ActiveState.
Related
I'm the upstream- and Debian maintainer of a Python library which is installed as a dependency of a required package in the Debian ecosystem, so this library is pretty much installed on every Debian system. I'm trying to support older Python versions as long as possible and my rule of thumb for this package is to support versions down to whatever is currently in Debian/stable. However, there is also Debian/oldstable (even /oldoldstable) and I wonder if there are some guidelines that help to make the decision which Python versions can be dropped which should be supported still?
The most relevant documentation for the issue is probably the Debian Python Policy, but I'm unable to find the information here.
As far as Debian is concerned, the package you publish should support the currently supported Python versions. So if you published a package when oldstable was still stable, the package you published then should have supported the oldstable Python versions. When you publish something now, the current stable is your target.
But going back in time, there is no particular reason for an oldstable user to be disappointed if some current packages are not usable on their platform; the decision to use an old system is usually motivated by a desire to maintain it for a longer time, not make it do new things which were not possible at the time it was configured.
Of course, there are situations where you want to support older systems. If you publish a tool for forensic analysis of hacked systems, you really want to be able to run that on older versions, too; but this is dictated by other factors then.
I am not a regular Linux user so this might be completely trivial question. I am running 6.2 PUIAS version i386_64 on one of my GPU based "super" computers due to the unavailability of NVidia drivers for NetBSD. The installed version of Python is 2.6.6. I need 2.7.2 Python and newer version of scipy, numpy, matlibplot and friends. I have PUIAS and EPEL repositories enabled. However they do not have newer versions of Python. What is the "recommended" way to install newer version of Python without braking the system which depends on it. I am not interested in Python 3.2 due to the lack of libraries for scientific computing.
When the install-Python-from-source routine tells you to use make install, type make altinstall instead. This will leave the normal python executable untouched and instead create python2.7 for you to use. Install the other packages from source using this new executable. Don't forget to change the shebang line in your scripts accordingly.
I am going to answer my own question. For people who are using Python for scientific computing on RedHat clones (PUIAS for example) the easiest way to get all they need is to use rpm package manager and Enthought Python Distribution (EPD for short). EPD installs everything in a sandbox so system tools which are based on an obsolete version of Python are not massed up. However, paths have to be adjusted for system or even easier on the user base so that the using shell invokes non-system tools. One should never compile Python from source unless you are interesting in Python itself or in porting it to your favorite operating system rather than in your own research!
For research related Python programs, I require Python 2.6 (or 2.7), numpy, scipy and matplotlib. Occasionally, I'm going to use other modules such as mayavi2 or numexpr.
The programs in questions will be exchanged between (Ubuntu) Linux and Windows and can be modified to work across platforms. The setup on the Windows side should resemble the Linux one as closely as possible. Integration with COM, .NET, or the Windows OS is not required.
I'm aware of the following options:
Python for Windows from python.org
ActivePython
Python(x,y), a bundle of Python with modules and GUIs
Enthought Python distribution, a bundle of Python with modules
Which of those will provide me most efficiently with a setup that just works? And how would they differ?
EDIT 2017-11-4: At this point in time Anaconda seems by far to be the best option. It is multi-platform, doesn't require admin/root permission, and it allows you to install multiple python versions in parallel.
Original post
The easiest way to install all the python libraries necessary for scientific computing is to install either Python(x,y) or Enthought Python Distribution (EPD). Both offer a fairly similar set of packages (including numexpr and mayavi2), so it's probably just a matter of personal preference. I prefer Python(x,y) because it is fully open source, whereas EPD is a commercial product with a free edition. You can compare the included packages for EPD and Python(x,y).
Both these options are much better than using the standard python (or ActiveState) then manually installing all the required scientific packages. Both should work well with code transported from Linux. It's worth mentioning that EPD also has a Linux version, so if you need all packages and versions to be absolutely identical between Windows and Linux setups, this might be the way to go.
Edit:The win32-superpack is a good option if you just want a few basic scientific packages, but if you want more complex things like mayavi, you'd need to install them yourself.
Edit 2013-05-03:
There are now a couple of other options which are also worth considering: winpython and anaconda
The question is old, but the answer nowadays to this question will always be Anaconda, so I thought I provide you a link to it.
Not only for scientfic purposes - it has all the libraries and tools for this, installed - but its also the best python distribution in general:
https://www.anaconda.com/download/
I have used the win32-superpack from the official SciPy distribution. It includes Python, NumPy, SciPy, matplotlib, etc. and everything works out of the box.
Maybe I should also comment on the packages on your list:
The standard Python distribution from Python.org does not include SciPy, as far as I know.
The Enthought distribution is installed on some of the computer clusters that I am using. It is linked against the Intel MKL and could be faster for linear algebra than the SciPy one. But it is a commercial package. Python programs developed with the SciPy distribution should, however, run without problems under Enthought, too.
I don't know anything about the other two distributions.
I bought a low-end MacBook about a month ago and am finally getting around to configuring it for Python. I've done most of my Python work in Windows up until now, and am finding the choices for OS X a little daunting. It looks like there are at least five options to use for Python development:
"Stock" Apple Python
MacPython
Fink
MacPorts
roll-your-own-from-source
I'm still primarily developing for 2.5, so the stock Python is fine from a functionality standpoint. What I want to know is: why should I choose one over the other?
Update:
To clarify, I am looking for a discussion of the various options, not links to the documentation. I've marked this as a Community Wiki question, as I don't feel there is a "correct" answer. Thanks to everyone who has already commented for their insight.
One advantage I see in using the "stock" Python that's included with Mac OS X is that it makes deployment to other Macs a piece of cake. I don't know what your deployment scenario is, but for me this is important. My code has to run on any number of Macs at work, and I try to minimize the amount of work it takes to run my code on all of those systems.
I would highly recommend using MacPorts with Porticus for managing your Python installation. It takes a while to build everything, but the advantage is that whatever you build yourself will be built against the same libraries, so you won't have to futz around with statically linked shared objects, etc. if you want your Python stuff to work with Apache, PostgreSQL, etc.
If you choose to go this way, remember to install the python_select port and use it to make your system use the Python installed from MacPorts.
As an added bonus, MacPorts has packages for most main-stream Python eggs, so if you should be able to have MacPorts keep you up-to-date with the latest versions of all that stuff :)
Here's some helpful info to get you started. http://www.python.org/download/mac/
Depends what you are using python for. If you are using MacOS funitionality and things like PyObjC you are probably best of with MacPython or the python provided by Apple.
I use Python on my Mac mostly for development of server side applications which later will run on FreeBSD & Linux boxes. For that I have used fink python for a few years and ever since MacPorts python. With mac ports it is simple to add required c modules (like database driver etc). It's also easy to keep two python Versions (2.5 & 2.6 in my case) around.
I used "compile your own" python to test pre-3.0 python but generally I find managing dependencies to c modules painfull if done by hand.
Thanks to easy_install installing pure python modules is fast and easy for all the options mentioned above.
I was never very much an IDE person. For development I use command line subversion installed by MacPorts, Textmate and occasionaly Expandrive do directly access files on servers. I personally are very dependent on Bicyclerepairman for Textmade to handle my refactoring needs.
Others seem to be very happy with Eclipse & Pydev.
How about EPD from Enthought? Yes, it's large but it is a framework build and includes things like wxPython, vtk, numpy, scipy, and ipython built-in.
I recommend using Python Virtual environments, especially if you use a Timecapsule because Timecapsule will back everything up, except modules you added to Python!
Based on the number of bugs and omissions people have been encountering in Leopard python (just here on SO!), I couldn't recommend that version. e.g., see:
Why do I get wrong results for hmac in Python but not Perl?
Problems on select module on Python 2.5
I would choose MacPorts.
It does not eliminate your existing python supplied by Apple since it installs by default in /opt/local/bin (plays nice with it) and plus it is easy to download and install additional python modules (even binary modules that you need to compile!). I use Porticus GUI to maintain my MacPorts installed list of packages, including python.
In my windows environment I use Eclipse and PyDev, which works quite well together, even if it's a bit sparse. Apparently the exact same environment is available for the Mac as well, so I suggest downloading Eclipse and using the internal update software function to update PyDev with the URL http://pydev.sourceforge.net/updates/. To look further into PyDev, look here.
Apple's supplied python is quite old – my tiger install has 2.3.5. This may not be a problem for you, but you would be missing out on a lot. Also, there is a risk that Apple will update it. I'm not sure if moving from 2.3.5 to (say) 2.4 would cause code to break, but I guess it's possible. This happened to perl people recently: http://developers.slashdot.org/article.pl?sid=09/02/18/1435227
Macpython is a framework build (as is Apple's, I believe). To be honest, I'm not sure exactly what that means, but it's a prerequisite for some modules, in particular wxPython. If you get python from macports or fink, you will not be able to run wxPython (unless you run it through X11).
And guess what was forgotten by every answer here ... ActivePython.
No compilation required, even for third-party modules such as numpy, lxml, pyqt and thousands of others.
I recommend python (any python?) plus the ipython shell. My most recent experience with MacPython was MacPython 2.5, and I found IDLE frustrating to use as an editor. It's not very featureful, and its' very slow to scroll large quantities of output.
In our group we primarily do search engine architecture and content integration work and most of that code base is in Python. All our build tools and Python module dependencies are in source control so they can be checked out and the environment loaded for use regardless of os/platform, kinda similar to the approach virtualenv uses.
For years we've maintained a code base compatible with Python 2.3 because one of the commercial products we use depends on Python 2.3. Over the years this has caused more and more issues as newer tools and libraries need newer versions of Python since 2.3 came out in ~2004.
We've recently decoupled our build environment from dependencies on the commercial product's environment and can use any version of Python (or Java) we want. Its been about a month or so since we standardized on Python 2.6 as the newest version of Python that is backwards compatible with previous versions.
Python 3.0 is not an option (for now) since we'd have to migrate too much of our code base to make our build and integration tools to work correctly again.
We like many of the new features of Python 2.6, especially the improved modules and things like class decorators, but many modules we depend on cause the Python 2.6 interpreter to spout various depreciation warnings. Another tool we're interested in for managing EC2 cloud cluster nodes, Supervisor doesn't even work correctly with Python 2.6.
Now I am wondering if we should standardize on Python 2.5 for now instead of using Python 2.6 in development of production environment tools. Most of the tools we want/need seem to work correctly with Python 2.5. We're trying to sort this out now before there are many dependencies on Python 2.6 features or modules.
Many Thanks!
-Michael
I wouldn't abandon 2.6 just because of deprecation warnings; those will disappear over time. (You can use the -W ignore option to the Python interpreter to prevent them from being printed out, at least) But if modules you need to use actually don't work with Python 2.6, that would be a legitimate reason to stay with 2.5. Python 2.5 is in wide use now and probably will be for a long time to come (consider how long 2.3 has lasted!), so even if you go with 2.5, you won't be forced to upgrade for a while.
I use Python 2.5 for all my development work, but only because it's the version that happens to be available in Gentoo (Linux)'s package repository. When the Gentoo maintainers declare Python 2.6 "stable"*, I'll switch to that. Of course, this reasoning wouldn't necessarily apply to you.
* Python 2.6 actually is stable, the reason it's not declared as such in Gentoo is that Gentoo relies on other programs which themselves depend on Python and are not yet upgraded to work with 2.6. Again, this reasoning probably doesn't apply to you.
My company is standardized in 2.5. Like you we can't make the switch to 3.0 for a million reasons, but I very much wish we could move up to 2.6.
Doing coding day to day I'll be looking through the documentation and I'll find exactly the module or function that I want, but then it'll have the little annotation: New in Version 2.6
I would say go with the newest version, and if you have depreciation warnings pop up (there will probably be very few) then just go in a find a better way to do it. Overall your code will be better with 2.6.
To me the most important to stick with python 2.5+ is because it officially supports ctypes, which changed many plugin systems.
Although you can find ctypes to work with 2.3/2.4, they are not officially bundled.
So my suggestion would be 2.5.
We're sticking with 2.5.2 for now. Our tech stack centers on Django (but we have a dozen other bits and bobs.) So we stay close to what they do.
We had to go back to docutils to 0.4 so it would work with epydoc 3.0.1. So far, this hasn't been a big issue, but it may -- at some point -- cause us to rethink our use of epydoc.
The 2.6 upgrade is part of our development plan. We have budget, but not fixed schedule right now.
The 3.0 upgrade, similarly, is something I remind folks of. We have to budget for it. We won't do it this year unless Django leaps to 3.0. We might do it next year.
I think the best solution is to give up the hope on total uniformity, although having a common environment is something to strive for. You will always will be confronted with version problems, for example when upgrading to the next best interpreter version.
So instead of dealing with it on a per issue base you could solve this problem by taking a good look on your release management.
Instead of releasing source, go for platform depending binaries (besides the source distribution).
So what you do is that you define a number of supported CPU's, for example:
x86-32, x86-64, sparc
Then which operating systems:
Linux, Windows, Solaris, FreeBSD
For each OS you support a number of their major versions.
Next step is that you provide binaries for all of them.
Yes indeed this will require quite some infrastructure investment and setting up of automatic building from your repositories (you do have them?).
The advantages is that your users only have 'one' thing to install and you can easily switch versions or even mixing versions. Actually you can even use different programming languages with this approach without affecting your release management too much.