Short version: As a proof of concept, I converted the Python koan
about_strings (which you can find
for Python 2, or
for Python 3) into an IPython notebook. Here’s the
notebook on nbviewer.
I use the Panda3D video game engine to develop experiments for my research. I needed to install a development version that included some bugfixes, but unfortunately, installing Panda3D on OSX is not the easiest task to accomplish. The development builds they provide are unfortunately only 32-bit, but I needed to be able to run my Panda3D code alongside libraries like NumPy, which I had installed as 64-bit (which is the default on OSX). For a while, I tried to get NumPy/SciPy/etc. installed for 32-bit, but failed, and ultimately was able to get Panda3D compiled for 64-bit Python 2.7. Here are the steps that I took in order to compile it; hopefully they will be useful to others (and at the very least, a reference for myself going forward!)
Today, I found myself in a situation where I had a few different classes inheriting from each other, e.g.:
1 2 3 4 5 6 7 8 9
Specifically, each of these classes was a test class that I was
C had different
setup methods than
A, but otherwise ran the same test. However,
nosetests -v doesn’t
print out the name of the method’s class, only the docstring, which is
of course the same for all three classes. This made it very difficult
to tell which method was actually failing.
To resolve this, I wrote a metaclass to intercept each class at creation time and rewrite its docstrings to be prefixed with the name of the class. This was probabily overkill, but I’d been itching to play around with metaclasses for a while and decided this was a semi-valid excuse.
When collecting data, how do you save it?
There are about a million different options. In Python, you can choose from many different libraries:
… just to name a few. Over time I’m fairly certain that I’ve managed to save data (whether behavioral or simulation) in all of these formats. This is really inconsistent: it makes it difficult to know what encoding any particular dataset is in, let along the format of the data itself, and it means I end up writing and rewriting code to do saving, loading, parsing, etc., more times than I ought to.
As you may be able to tell, the look of this site has drastically changed. I’ve been meaning to overhaul the theme for a while, and I decided I also wanted to try something different from Wordpress. In particular, I wanted more flexibility with embedding code, which Octopress seems to be particularly good at:
1 2 3 4
Also, I just really like how Octopress blogs look by default. I’ve been fiddling with the theme on this today, and I’ll probably continue to fiddle with it going forward. Because Octopress serves static content, I feel like I have somewhat more control over the look and feel of my blog — and importantly, I can try out changes locally before deploying them, which was not something I could do with Wordpress.
Hurray for change and learning new tools!
I’ve realized that I don’t blog very often because I tend to write very long and thorough posts. In an effort to try to start blogging more, I’m going to let myself off the hook some of the time and just write about something short. Perhaps this will get me more in the habit of writing, which will then lead to more in-depth posts!
Anyway, today in our lab meeting I gave a presentation on using git. As I was working on the presentation the past few days, I struggled with a way to answer a question which I’ve been asked multiple times:
Why does it take so many steps to make a commit?
In my last post, I talked about how to set up Emacs as a Python IDE. Since then, two things have changed:
- I got a Macbook Air. Switching from Linux to Mac required a few (mostly minor) changes to my Emacs configuration.
- I have begun using the fabulous IPython Notebook, which has really helped me organize my code and streamline my workflow.
In this post I’ll tell you how switching to a Mac has affected my configuration. In a future post (coming soon!), I’ll talk about the IPython Notebook, how I set it up for my configuration, and how it’s really improved my Python development environment. You can find the emacs configuration associated with this post here.
Update 04/08/2014: It seems like this post has been helpful for a lot of people, which really makes me happy! I just wanted to let new readers coming by know that the configuration I present in this post is out-of-date. However, I have my Emacs configuration on GitHub, and do try to keep it up-to-date. If you have any difficulties getting the configuration in the GitHub to work, please do submit a bug request and I will try to help you fix the problem.
As I mentioned in last week’s post, I am a heavy Emacs user and find it invaluable as an environment for my research. In particular, I use Emacs most for data analysis and modeling in Python, including an interface to IPython, which allows me to quickly switch between writing and running snippets of code. This proves to be a great replacement MATLAB, at least in my opinion.
I frequently get requests for my .emacs configuration file or questions about how I have such an environment set up. As such, in this post I’m going to document how to set up your Emacs configuration to support rapid Python development, including the plugins I have installed and the keyboard shortcuts I use most often.
Note that I am running GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK Version 2.24.5). I have never tried running it under OSX or Windows, so I can’t guarantee that these instructions will transfer, but you are welcome to try. If you run into any inconsistencies, feel free to send them to me and I will update this post accordingly!
Also, if you are new to Emacs, please read my beginner’s guide first, as I will be assuming familiarity with basic Emacs functionality and terminology. I will also assume you can at least read and understand LISP to some extent (but you don’t necessarily have to be able to write it).
I’ve been using Emacs () as my primary text editor for several years now. It takes some getting used to — the keyboard shortcuts are completely different from what you’re probably familiar with, e.g. Ctrl-C for copy and Ctrl-V for paste. Despite the somewhat steep initial learning curve, however, I find that Emacs is invaluable for rapid coding and for flexibly editing all different types of files in the same environment.
I remember how overwhelming it was to figure out how to do anything when I first got started, so in this tutorial I’m going to aim to give you the basics to get started. This is by no means a complete guide to Emacs (though if you have suggestions for things to add, I’d be happy to do so), but hopefully should be enough to start comfortably using Emacs as a text editor.
This tutorial is mainly for people who have primarily used GUI text editors and coding environments and are not used to a primarily text-based program, running commands in the editor itself, and/or using large amounts of keyboard shortcuts.
Well, it has been a while since I’ve posted. Over the summer I moved to beautiful Berkeley, California to start my PhD in Psychology at Cal. Moving has kept me pretty busy, but as things are starting to settle down a bit, I’ve decided to start making an effort to blog regularly (even if it’s just a short and simple post like this one).
Most posts are probably going to be Python-related (particularly from a scientific computing point-of-view). If you have any requests or suggestions, please let me know! I’m always open to ideas.
Often when I’m doing data analysis, I will need to save many figures to disk at once. For example, if I’m looking at the distribution of human responses to every stimulus I have (say, around 60 different stimuli), I’m going to need a different plot for each. Matplotlib actually has a pretty straightforward function for saving figures, but there’s a little bit of scaffolding that I like to have around it by default.