There are a number of Vim plugins to show the current Python class and method name or function name (e.g., this). However, they can be extremely "heavy" (the linked example requires Vim compiled with Python, and is pretty slow when indexing a large Python file) and moreover, all seem to be geared to showing the information dynamically in the status bar. While the latter might be desirable in some contexts, the required binding to a CursorHold trigger coupled with the slowness in indexing, make it clumsy to use when navigating large files. Sometimes, all that is wanted or needed is an "on-demand" brief display of the information. The following code takes care of this. When sourced into your Vim session, it echos the current Python class and method name or function name when invoked via "<Leader>?" or ":EchoPythonLocation".
There are a number of solutions for executing Python code in your active buffer in Vim.
All of these expect the buffer lines to be well-formatted Python code, with correct indentation.
Many times, however, I am working on program or other documentation (in, for example reStructuredTex or Markdown format), and the code fragments that I want to execute have extra indentation or line leaders.
SciPy and Numpy are great packages for scientific computing.
Unfortunately, installation on Mac OS X 10.7 Lion is not a very smooth affair.
It can be a pain for moderately-experienced developers, and a nightmare for novice end-users.
While Python comes with many "batteries included", many others are not. Luckily, thanks to generosity and hard work of various members of the Python community, there are a number of third-party implementations to fill in this gap. For example, Fisher's exact test is not part of the standard library.
It is past 4 am, and the bug hunt is over. It was a weird one. One that I'll remember. It led me on a wild exhausting chase through dark nooks and crannies of a horribly-written nightmare of a code base. What made it weird was that, with the same random number seed, I got different behavior depending on whether there were some (debugging-related) print statements in some parts of code.
Even if these statements were in parts of the code that were entirely separate from where the failure was happening.
R is like a microwave oven. It is capable of handling a wide range of pre-packaged tasks, but can be frustrating or inappropriate when trying to do even simple things that are outside of its (admittedly vast) library of functions.