Tuesday, December 24, 2013

WinPython, a portable scientific Python distribution for Windows(32&64bit)

Following my recent post on a free open-source 64-bit Python distribution for Windows, I was able to create the project (WinPython, "a portable scientific Python distribution for Windows") and write some code to generate a portable Python distribution from scratch (actually from existing distutils packages).

I've just uploaded WinPython v2.7.3.0beta2 for both 32-bit and 64-bit Windows platforms.

WinPython has its SourceForge project and everything is ready for downloads, discussions, bug reports and feature requests.

Enjoy! (I hope)

Thursday, January 24, 2013

Spyder v2.1.14 supports Python 3

Spyder v2.1.14 is an experimental release of Spyder which I've been working on lately. Its purpose is to demonstrate the possibility for supporting both Python 2 and Python 3 with a single code base.

Great news: it works!
(and I must admit that it was quite easy and that it took me far less time than expected)

So now you may switch to Python 3 with Spyder at your side.
For example, Windows users may already start working with a full featured scientific Python ecosystem including Spyder thanks to WinPython v3.3 which first beta was released recently. WinPython is now supporting both 32bit and 64bit versions of both Python 2 and Python 3, and all this in a portable way. In other words, with WinPython, you may run four versions of Python on the same machine without any prior configuration and without any interference: fast switching from a Windows-integrated (Windows explorer/registry integration) Python version to another is even possible!

Note that even if  Spyder v2.1.14 supports Python 3, the forthcoming Spyder v2.2 release won't support it: Python 3 support will be officially implemented in Spyder v2.3 which will hopefully be released shortly after v2.2.

Sunday, August 5, 2012

Scientific Python distribution for Windows 64bit

As one of my image processing software (mainly based on NumPy, SciPy, guidata and guiqwt) is being limited by the "2GB per application" memory limit due to the fact that I'm using a 32bit build of Python on Windows, I'm currently thinking of switching to Python 64bit. That's why I've been recently investigating the 64bit/Windows/Python ecosystem.

1. The NumPy/SciPy building issue on Windows 64bit.

According to experienced developers, there is no decent open-source (free) Fortran compiler for the Windows 64bit platform. As a consequence, it's impossible to build NumPy or SciPy on this platform using only free and open-source tools. That's why there is no official Windows 64bit binaries for these two libraries. The only ready-to-use installers available out there were prepared by Christoph Gohlke (using Intel Fortran compiler, a.k.a. 'ifort') and these are clearly unofficial binaries. Furthermore, Christoph has built two different installers for NumPy: one unoptimized and one optimized with the Intel Math Kernel Library (MKL), hence providing better performance. And Gohlke's SciPy 64bit binary package (the only one available freely online) require NumPy MKL. The problem is that, according to Christoph Gohlke, the MKL license does not allow me (or anyone else) to redistribute these binaries, unless I have purchased such a license. It is still unclear to me if the end user would also require this license too. Hopefully no. Let's assume that. Besides, after reading carefully the Intel MKL License terms, I'm quite sure that I can redistribute the MKL-based NumPy built because it's just runtime redistribution. So I think I will purchase an Intel Fortran Compiler license (including MKL) to be able to rebuild NumPy and SciPy in the near future but in the meantime I will just redistribute the packages built by Christoph Gohlke.

2. The distribution: how? when?

I'm planning on releasing publicly a completely free 64bit Python distribution by the end of 2012 (and I'll probably release a 32bit version too). To achieve this, I can't go on with Python(x,y): the concept has its limits and it's beginning to be difficult to maintain. So I'm thinking of something completely different: a portable Python distribution with a built-in package manager which would be able to install/uninstall Python packages to/from the distribution using standard Python installers (made with the standard Python library 'distutils') - support for eggs won't be added as I had very disappointing results with their unconventional way of installing packages, sometimes messing with the sys.path list. This portable distribution would also embed some useful tools like SciTE, WinMerge or TortoiseHg. But, unfortunately, as mentioned above (point 1.), there won't be any integrated C/C++/Fortran compiler in the 64bit edition (I'll probably integrate MinGW with gfortran in the 32bit edition of the distribution).

3. First experiments...

I've already done a bunch of tests and this is working great. I just have to take the time to write scripts automating the distribution creation process from scratch: installing the official Python distribution (.msi file) to a folder, install PyQt by unzipping the official NSIS installer, create the batch scripts for running Python (or Spyder) in the appropriate environment, and so on. My current portable distribution test is able to run Spyder with all basic scientific packages. That is very interesting: a complete and ready-to-use (without any installation requirement) scientific Python distribution on a USB key!

To be continued...


Update
This new project has now a name: this is WinPython. Check out the website for more informations.

Friday, November 4, 2011

Spyder v2.1 is available

After a year of hard work on stability, performance and new features, Spyder v2.1 is now available for Windows XP/Vista/7, GNU/Linux and MacOS X.

This release introduces major enhancements and new features:
  • Large performance and stability improvements
  • PySide support (PyQt is no longer exclusively required)
  • PyQt API v1 and v2 support
  • New profiler plugin (thanks to Santiago Jaramillo, a new contributor)
  • Experimental support for IPython v0.11+
  • And many other changes

We [the Spyder development team] are all very excited by this new release: Spyder is now becoming the [GUI-based] scientific development environment. Its future seems very promising. First there is the PySide support and the PyQt API v1/v2 support which were strategically essential (this will also help us supporting Python 3 in time). Second there is a cleaner and optimized code: this was critical for Spyder's behavior to be the closest possible to a standard Python interpreter. Third there is a very stable application: a lot of crashes and segmentation faults were fixed during the last year. Last, but not least, the future looks bright thanks to the new project members: we are now 5 committers and 6 contributors.

Stand-alone executable on Windows platforms
Note that, on Windows platforms, Spyder is also available as a stand-alone executable (don't forget to disable UAC on Vista/7). This all-in-one portable version is still experimental (for example, it does not embed sphinx -- meaning no rich text mode for the object inspector) but it should provide a working version of Spyder for Windows platforms without having to install anything else (except Python 2.x itself, of course).

Help needed
More than ever, we welcome any contribution that helps making Spyder an efficient scientific development/computing environment. Join us to help creating your favourite environment!

Sunday, September 11, 2011

New enhanced scientific Python interpreter

As I mentionned in my previous post, the standard Python interpreter provided by Spyder's console has been considerably enhanced. Moreover, despite these interesting enhancements, this is based on a real Python interpreter, not an emulation.

The scientific startup script mentionned in my previous post was integrated in Spyder's development version (under the name scientific_startup.py).

The goal of all these recent changes was to provide a MATLAB-like experience with a minimum of requirements: NumPy, SciPy, Matplotlib and Spyder, that's all.

And here are two screenshots of the result (Spyder was executed in `light` mode: `spyder --light`):


Sunday, September 4, 2011

No IPython v0.11 support in Spyder's console, but standard Python interpreter enhancements

It's been a month since IPython v0.11 public release and I've been trying to solve issues related to IPython support in Spyder's console, all in vain. At first, I thought that it was only a problem on Windows platforms, but apparently it is not. The more I think about it (and the more I spend time on it), the more I doubt that there will ever be a decent support of IPython >=v0.11 in Spyder's console. In the meantime, I have fixed a couple of bugs related to the new IPython plugin: this new plugin will probably be the only way to run IPython >=v0.11 within Spyder.

So, to compensate this lack of IPython support in Spyder's console, I have implemented the following enhancements for the standard Python interpreter (this is not much, but it provides all the IPython features I am using personnally):

  1. I have fixed the PyQt input hook issue on Windows platforms. Before this revision, the console was crashing (non-responsive actually) on Windows platforms after trying to manipulate Qt objects interactively, like interactive plotting with Matplotlib for example. Now, when enabling the "Replace PyQt input hook by Spyder's" option (which is enabled by default on Windows platforms), the standard Python interpreter may be used to do interactive plotting, even on Windows.
  2. Plus, I have implemented some basic special commands in the standard Python interpreter (see here more details), adding support for %pwd, %ls, %clear or !dir (or !ls on UNIX platforms), etc. (I haven't implemented the %edit, %run and other similar commands which have really no use within Spyder).
  3. And I have fixed a bug with PYTHONSTARTUP substitution option (the packages imported in the startup script were not available in the Python interpreter).

These three changesets were intended to facilitate the use of standard Python interpreter as an interactive computing shell. I've also created two PYTHONSTARTUP scripts (on my machine), one to support Matplotlib's pylab interface and the other to support guiqwt's interactive plotting mode:

  • Matplotlib's startup script:
print "Running pylab startup script...",
# Import modules following official guidelines:
import numpy as np
import scipy as sp
import matplotlib as mpl
import matplotlib.pyplot as plt
# Pollute the namespace but also provide MATLAB-like experience:
from pylab import *
# Enable Matplotlib's pylab mode:
ion()
print "done."
  • guiqwt startup script:
print "Running guiqwt startup script...",
# Import modules following official guidelines:
import numpy as np
import scipy as sp
import guiqwt.pyplot as plt
import guiqwt.io as io
# Pollute the namespace but also provide MATLAB-like experience:
from numpy import *
from guiqwt.pyplot import *
# Enable guiqwt's interactive mode:
ion()
print "done."

With these startup scripts, I have my own IPython shell (not as powerful as IPython, of course) but it suits my needs... why not yours?

To select you own startup script, go to Tools > Preferences > Console > Advanced settings:
I think I'll add these startup scripts to Spyder v2.1 but I don't know how exactly. Maybe the simplest way would be to change the settings GUI above and add a third choice: "Build-in startup script: " with a combo box allowing to choose a script between the two scripts above (and others).

Saturday, August 13, 2011

Preview of the new IPython plugin for Spyder

Here is a first preview of the new IPython plugin which will be available in Spyder v2.1 (to be released in September 2011, but the first beta will hopefully be available in a few days):


Important notes :

  • This feature is still experimental and will remain so until Spyder v2.2 (scheduled for December 2011).
  • It requires IPython v0.12dev (i.e. the current IPython development version, available through the github repository).

The idea is to start a new IPython kernel within the "Console" plugin (bottom left of the screenshot above), then a new IPython frontend dockwidget is created automatically (top left of the screenshot above). This first implementation already supports the Variable Explorer (top right of the screenshot above) through the IPython kernel associated to the frontend but nothing else is supported (link with the Editor, the Object Inspector, and so on).

In the "Console" plugin preference page, the user may change the IPython kernel command line options (defaults are: "python --pylab=inline").