This week we welcome Cyrille Rossant (@cyrillerossant) as our PyDev of the Week! Cyrille is one of the core developers behind the VisPy project. He is also the author of several Python books like Learning IPython for Interactive Computing and Data Visualization and IPython Interactive Computing and Visualization Cookbook. His blog is also well worth checking out. Let’s take some time to get to know our fellow Pythonista better!
Can you tell us a little about yourself (hobbies, education, etc):
I have a background in math and computer science, and a PhD in neuroinformatics. I’ve been passionate by programming since I was 6, and now I have the chance to combine my passions for science and programming by developing software in a research lab.
As for hobbies, I enjoy listening to all kinds of music, playing piano, and doing photography.
Why did you start using Python?
When I started my PhD eight years ago, I’d been using MATLAB for a couple of years, and my new lab was just starting to use Python. It was not as popular as it is now, and it took me a while to switch from MATLAB. Of course I’ve never looked back!
Now I use Python for most of my software projects. I continue to be amazed by how such an apparently simple language can be so versatile and powerful.
What other programming languages do you know and which is your favorite?
I also write code on graphics devices or GPUs, be it for numerical computing with CUDA or OpenCL or for graphics with OpenGL. I’m looking forward to learning Vulkan (https://www.khronos.org/
I’d like to learn new languages in the near future. Rust, Haskell, Swift, and others are on my short list. Functional programming looks quite appealing to me and I think I’d appreciate this different way of thinking.
What projects are you working on now?
As part of my job, I’m developing a data analysis library targeting a very particular type of neurophysiological data. A major component of this project is a GPU-based visualization library in Python that we’ve created with several other developers (http://vispy.org/).
Recently I’ve been working on tools to manipulate and convert documents in markup languages. I discovered Markdown a few years ago and I’m now using it for all of my writings. I’ve written ipymd (https://github.com/rossant/
I’m now extending this project to support many other formats, aided by the fabulous pandoc library (http://pandoc.org/).
Finally, I have several writing projects right now. I enjoy learning new things and explaining them as clearly as I can.
Which Python libraries are your favorite (core or 3rd party)?
Since I’m doing a lot of numerical computing with Python, I don’t use the standard libraries that much. However I use many third-party libraries. I really like NumPy and matplotlib, although they’re starting to be old and they have some weaknesses. Numba is really impressive and I’m keeping a close eye on DyND (https://github.com/libdynd/
scikit-learn is one of the best libraries I know. The API is limpid and the documentation excellent.
Otherwise I’m a big fan of the libraries made by Armin Ronacher and the Pocoo Team (http://www.pocoo.org/), notably Flask, jinja, click, and Sphinx. The APIs are well designed and very Pythonic while the documentation is always amazing.
Where do you see Python going as a programming language?
Python has been steadily growing in popularity since I’ve used it. It is at the top at the moment and I think it will continue to stay there for a while.
I’m expecting a lot from the Jupyter project. The developers have an ambitious goal that might lead to web interfaces, interactive dashboards, and graphical applications with Python-powered backends (among other languages). I think Python really needs this.
That being said, a few things concern me about Python’s future.
The Python 2 to 3 transition was messy to say the least and has done some harm to the community. Also, in my opinion, the packaging system is unnecessarily confusing. Fortunately conda has solved part of the problem.
CPython has its weaknesses, notably regarding performance, and the squabble with PyPy is doing no good. I hope the two communities will join forces eventually. I’m keeping a close eye on alternative implementations such as Pyston by Dropbox (http://blog.pyston.org/). I think there are good chances that the future of Python will involve LLVM and JIT techniques.
What made you decide to write multiple books about Python?
I’ve wanted to write books for a long time. One day, I received an email from Packt. They were looking for an author to write a short book (a “minibook”) about IPython. I think they found me because I had written a few blog posts about IPython. I took the bait and that’s how I found myself writing a book about IPython! It was a fun experience. The writing didn’t take long, the book was published and the readers seem to have liked it.
A few months later, they proposed me to write a longer, more advanced book (“cookbook”, see http://ipython-books.github.
This time, the project was far more ambitious and appeared to represent way more work than anticipated. There is really a qualitative difference between writing a 120-pages book and a 500-pages book. This might be also due to the format of the book, which consists of more than 100 independent “recipes”, each one covering a different subject with a dedicated example. While I enjoyed the writing, I had quite a few technical issues as I described in a blog post (http://cyrille.rossant.net/
Last year, I wrote the new edition of the minibook (http://ipython-books.github.
Despite the issues I had with this new edition too (blog post to come later), I plan to write more books in the future.
Can you tell us what you learned while writing your books?
I’ve learned that to estimate how much time it will take to write a book, or more generally to complete any significant project, you have to make your worst-case estimation and multiply it by 3.
I’ve learned that when you write a lot of text, you should ensure that you have the tools to manipulate and transform it automatically. Otherwise, you expose yourself to extremely tedious manual work.
The problem is that some publishers like Packt are stuck with Word, which is why I had to invent my own tools to automatically convert documents between notebooks, Markdown, and Word.
It is best to plan in advance the file formats, workflows, and tools you’re going to use for your project, because it is quite risky to change after you’ve started.