I think it is appreciated in some circles, particularly people who do programming as a means to something else (eg science research stuff). In my experience looking and playing with it tho (including diving in a bit), it just seems like a lot of complicated code for fancy repl work. Too much tight integration with their way of doing it. Personally, I was extremely interested in making ipython tie in deep with vim, but even the api provided was too complicated for the functionality it provided, given I was using outside the expected ways.
IPython has seen quite a large refactoring in the last couple of years, and now there is a popular vim-ipython integration: https://github.com/ivanov/vim-ipython
Thanks for mentioning this! I read this bit on the project page:
The big change from previous versions of ipy.vim is that it no longer requires the old brittle ipy_vimserver.py instantiation, and since it uses just vim and python, it is platform independent (i.e. works even on windows, unlike the previous nix only solution). The requirements are IPython 0.11+ with zeromq capabilities, vim compiled with +python.
And had a moment of panic. As the guy who wrote ipy_vimserver.py (the playing mentioned in my previous post) I am both glad that this awesome project ivanov wrote evolved from it, and horrified that people were using it :). (particularly after searching for ipy_vimserver on google, and finding a lot of issues people were having...)
ipython provides more features but requires significantly more magic to do so which can have unintended side-effects e.g. by triggering stuff through introspection that the user didn't intend to trigger.
Actually you don't even have to do that - just alias "python" for "bpython" and bpython automagically instantiates the actual python if it is passed arguments, i.e. "bpython foo.py" is essentially the same as "python foo.py" - this feature was implemented for this reason, so you could just make an alias.
