We had our first official Vispy Code Camp this week. I and the other core developers of Vispy were kindly invited by the European Synchrotron Radiation Facility. We presented our young library to software engineers from the ESRF and other European synchrotron facilities. It was also the occasion for us to make a gentle introduction to modern OpenGL, as many attendees didn't have experience in real-time GPU rendering. We discovered various scientific use cases in need of high-bandwidth, low-latency real-time visualization of big data.
tl;dr: Although not perfect, Python is today one of the best platforms for scientific computing. It's getting even better everyday thanks to the amazing work of a vibrant and growing community. I reviewed Python's strengths in a previous post. Here, I cover the more sensitive issue of its weaknesses.
Why use Python for scientific computing? This is a legitimate question. For us, regular Python users, using Python is so natural that we sometimes forget that this choice is not obvious for everyone. Matlab is very widely used in some communities (e.g. experimental biologists) and choosing a different platform requires extensive proselytism. We need to find the right words to convince people that Python is really the future for scientific computing.
When one starts using the IPython notebook seriously, there is often the need to open a server in the current directory to open or create a new notebook. Whereas this is straightforward on Unix systems (e.g. ipython notebook --pylab inline) since users typically use mainly the command-line, it is a bit more cumbersome from the graphical Windows Explorer. One needs to open a console, go in the current directory, type the command, open the browser, and go to http://127.0.0.1:8888 (unless the browser automatically launches).
Here is a simple method to simplify the process. It is based on the great AutoHotKey tool which lets one automate repetitive tasks with e.g. keyboard shortcuts.
I am developing a scientific application in Python with a graphical user interface in Qt. Some end-users use OS X or Linux, but most of them are Windows users who are not familiar with Python or with a command-line interface. It is notoriously difficult to distribute Python applications to end-users who are not programmers, and it's a common criticism that is made against Python.