I love that the website has an "Alternatives" section linking to competitors. That's not only classy, it also communicates confidence and inspires trust.
I've used bpython a lot in the past - mostly for it's instant syntax highlight and autocompletion, but I recently discovered ipython qtconsole and I can say it's much better (yes, it's not in the console, but I'm ok with that). Its syntax highlighting is as good as bpython's, but allows me to use it like a text editor and go up a few lines, edit, execute. Bpython cannot do that.
Also, bpython is a bit buggy when it comes to pasting about a page worth of code/string. In the nice case the syntax highlight gets confused. In the not so nice - it becomes completely unusable, so that I have to kill it.
Heh, The overall sentiment in irc freenode #python is a general dislike of ipython and a recommendation of bypthon as a good alternative to the REPL. It's a pretty light alternative but I still generally use ipython these days.
The main reason for this is actually that IPython has had (and, by design, in some cases still does have) the "problem" that code that works in IPython can work differently to the standard Python interpreter. This meant that people quite often had problems where the solution was "run it in the actual python interpreter". When I first started writing bpython one of the design goals was that all code that runs in bpython would also run the same in the vanilla REPL. This is why there is no extended syntax such as that provided by IPython (I don't actually use it so can't give good examples, but I think you can do things like "object?" to get help etc.). IPython also had some issues with unicode and encodings that may have since been resolved.
This is the only good reason I would recommend bpython over IPython objectively. Other than that, it's just a matter of taste - bpython is just a standard shell with some nice features to aid the user whereas IPython has a whole host of features and extensions and integrations that make it a great tool for lots of people. I don't think you have to use one or the other and I don't see them as competing pieces of software. IPython is a great tool and seems to suit a lot of people, particularly those in the mathematic and scientific communities.
Let me put it this way: if IPython implemented all of the features that bpython has and bpython became entirely redundant then I would only be happy that people have a great tool to help them with their development and that bpython may have played a part in helping it get to that state.
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.
This is something I always loved about Python (as compared to other languages): There are several awesome interpreters available for it!
This one has a curses-based interactive GUI for docs and autocompletion.
IPython has this awesome qtconsole that can show matplotlib plots inline with the code. Then there is its HTML notebook which is probably awesome for presenting stuff.
Even IDLE is pretty cool, actually.
Is stuff like this available for other programming languages? I know Matlab has something vaguely similar to IPython and I think the IPython notebook is inspired by mathematica?
In comparison IRB seems really boring to me. Does Ruby have a cool interpreter? Perl? R?
Most Lisps will integrate with Emacs out of the box as an "inferior lisp process" which supports something I think is more valuable: send code straight from an editor buffer to an embedded REPL. This completely removes the copy-and-paste step you have when working with a regular, detached REPL. One of the more impressive uses of this is with ClojureScript, which integrates the compiler with a bit of JS running in a browser to allow you to send Cljs code straight from your editor to the browser.
You can use SLIME with Common Lisp and Clojure which is similar but adds a number of features like hints, docs, and debugging, although it was originally designed for CL so Clojure support is less powerful.
There are definitely Emacs modes like this for other languages, and probably similar plugins or whatever for other editors.
Pry is pretty cool. It adds some debugger-like features and editor integration, adds some convenient built-in commands, and improves on the UI in similar ways to bpython.
The code that generates the completions [1] and displays them [2] is fairly simple. It uses a mix of scanning for a function's docstring, Python's built-in rlcompleter module [3] to generate the possible identifiers and keywords, its own module scanner for imports [4].
Hi. It's done using ncurses for the display (if you've ever worked with curses you can imagine how much of a headache the whole thing was). The introspection is done using the `inspect` module for the arg spec/doc string, and either inspect.getmembers or just dir() to get the attributes (it's been a while since I wrote it). We had to do some pretty weird stuff to get the attribute inspection to not trigger __getattribute__ for objects that implement it (i.e. to introspect without side-effects) but it seems to work pretty well.
I've been aware of this for awhile but this prompted me to play with it. Killer feature for me: it can be easily installed inside a virtualenv. This is not (last I checked) possible with ipython.
Just that "pip install ipython" has never worked properly for me when I'm inside an virtuelenv. I just tried it and it worked, so maybe the problem was fixed in the year or two since I last tried it, or maybe I was broken but have been fixed in the last couple years...
You have to "easy_install readline" into your virtualenv along with "pip install ipython" to get ipython's control characters working (otherwise ipython outputs what looks like garbled text). readline is easy_install'd rather than pip'd to because easy_install'd libs end up at the head of sys.path.
Yes, that's right. On Linux, you already have readline installed. But neither Macs nor IPython can ship with readline itself, because of the GPL, so by default you get the inferior libedit.
The Qt console doesn't require readline, but it does require Qt (and zeromq, and pygments).
Offtopic: with all these ipython/bpython's only thing that bugs me is need to do pip install -U ipython bpython (which downloads significant portion of bytes) in every virtualenv. I wonder if there's something like "pip install -U ipython --local-cache" option to copy existing ipython inside this virtualenv.
virtualenvwrapper has scripts that run after certain operations e.g. creating a virtualenv. I use this to install bpython, sphinx and tox into every new virtualenv.
This is really nice, but if you use vim you can use ScreenShell, which lets you execute parts of your buffer in a python interpreter (also works with lisp and any other language with a REPL). So you already have syntax coloring, completion, tags, etc.
I didn't know about this - we actually have a GTK version that needs some tidying up and packaging before we actually release it (if anyone is interested in helping with this that would be great as none of us use Windows - see the bpython website for details on how to get involved).
Could you possibly drop me an email or get me on IRC (again, see website for details) to let me know how this curses binary works on Windows ? It'd be great to add some documentation to the bpython site on this.
I installed bpython, but found it to be much more CPU intensive than ipython, for working on small machines (like a raspberry pi). Of course it's not a problem if you have a reasonnably decent hardware.
Edit: setting auto_display_list to False in ~/.bpython/config (not XDG compliant directory :( ) helps a lot. You can then use completion only when you need it.
This looks very nice, but you'll notice the Arabic unicode sample is rendering left-to-right, as almost all terminals currently are. I haven't seen any terminal beyond right-to-left specific ones that support proper Arabic yet :/
Hi, I don't have any knowledge of this kind of stuff so it would be very helpful if you could create an issue with some more info here: https://bitbucket.org/bobf/bpython/issues
At least then we know about the problem and can get around to fixing it. :)
Yes, I agree but I don't do any Arabic editing in terminal. The only time I bump up against this problem is when in Arabic IRC channels with irssi, and all the letters are separated and backwards. I usually switch to IRCCloud's web IRC when I'm chatting in Arabic channels anyways.
Over at Konversation, we implemented our bidi text behavior with the help of KDE's Arabic and Hebrew translators. Not only do we render the words correctly RTL, we also switch the overall directionality of the line based on the implied direction of the majority of characters within it, i.e. a line containing predominantly Arabic will be aligned to the right of the window with the nickname to the right of the message. This makes it rather pleasant to use for Arabic channels.
Edit: And I should mention that to my knowledge, KDE's terminal emulator Konsole will render Arabic text correctly as well. However irssi would need to do the alignment part.
is there a good emacs-mode for python that gives interactive development of the same level as inferior-lisp[1]? the python-modes i've seen only let you re-execute a file, but not a buffer or expression.
inferior-lisp makes all the problems bpython is trying to solve, irrelevant.
I patched python-mode to do this (also did something similar for node and a few other interpreters). Main thing is to add a "py-execute-line" routine and a few others as wrappers around the file execution code. If there's interest, might post as open source.
EDIT: here is a snippet
(defun py-execute-line (&optional async)
"Send the current line to the inferior python process using py-execute-region."
(interactive "P")
(save-excursion
(end-of-line)
(let ((end (point)))
(beginning-of-line)
(py-execute-region (point) end async)))
)
Standard python mode has also region evaluation and definition evaluation, which mostly account for that. Maybe I'm missing something here? What do you want from inferior-lisp that you don't have in python?
The worst thing is it's been at least two years since somebody first asked about this and we still haven't done it, even though it's really, really easy. :) I'll try to get this done soon if anybody is willing.
There doesn't seem to be a color theme that works with a standard black on white xterm. All of the defaults seem to be designed for Windows' white on black... Even defining 'prompt = k' (where 'k' is black) produces a nearly invisible grey prompt. Thanks but no thanks, I'll stick with vi/vim.
Terminals have had a black background since monitors first appeared. This makes sense because a monitor bombards you with light and having a black background minimizes the amount of light you're exposed to, and thus fatigue (looking into a monitor is essentially looking into a lamp). I suppose the first window managers later reversed this with white as the default background; perhaps this has to do with the idea of a desktop metaphor where white backgrounds mirror the typical color of paper, who knows.
Note that the tradition is not white on black, but gray on black, because the former has too much contrast which gives it a kind of afterglow effect. Monochrome monitors used to support only a single color, such as blue, orange or green. That's why green on black now has (IMHO silly) "retro" connotations.
Hi, sorry to hear you're having problems here - we made a lot of effort to make sure bpython can work in as many terminals as possible with as many colour arrangements as possible and it sounds to me like there should be a solution to your problem, so if you think you might be interested in using bpython please swing by #bpython on irc.freenode.net and we'd be happy to help you get it working. Even if you don't end up using it it would help out future users. :)
Not sure what you mean with the Windows comment - if you have your terminal in black-on-white, it's generally considered "inverse" colours on any platform. That means you probably have to pick white to get what your terminal shows as black.
And this has nothing to do with, nor provides an alternative to vi/vim.
