Bpython is a fancy interface to the Python interpreter | Hacker News Reader

Bpython is a fancy interface to the Python interpreter

bpython-interpreter.org

187 pointsllambda74 comments

I love that the website has an "Alternatives" section linking to competitors. That's not only classy, it also communicates confidence and inspires trust.

Pycon lightning talk about bpython:

http://www.youtube.com/watch?feature=player_detailpage&v...

Starts at 10:45

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.

Yeah. And I use ipython's %ed command for that kind of long scripts (emacsclient as editor). Also really great feature.

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.

When I saw ipython for the first time I was really excited but now I realize I never actually use it. Any thoughts about why it isn't appreciated?

I think ipython is widely appreciated in the scientific/numeric python community.

This seems right to me. ipython also has some features that go way beyond enhancements to the REPL.

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...)

Cheers.

ipython is very, very appreciated in scientific python communities.

It might be less so on the "engineering" side due to being perceived as more heavyweight?

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.

Check it again. It recently added a "Notebook" mode that you might find useful.

I for one found it very difficult to get into the habit of typing "ipython" instead of "python", which seems silly but really did stop me using it.

You could write a script called 'python' that runs bpython if passed no parameters and python otherwise.

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.

I have never really got this, I think ipython is the best thing since sliced bread.

(Not that I dislike bpython, just never had the desire to use it)

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?

> There are several awesome interpreters available for it!

Technically, it's not another interpreter (like IronPython or Jython), just an interface to the classic CPython REPL.

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.

> Does Ruby have a cool interpreter?

I don't know if it's cool, but I know of at least one alternative to irb: http://pry.github.com/

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.

> Does Ruby have a cool interpreter? Perl? R?

For Perl I use Devel::REPL (https://metacpan.org/module/Devel::REPL) but there are several others on CPAN (for eg: https://metacpan.org/module/Zoidberg) with varying levels of coolness.

for R, you're a fool (IMO) if you use anything but Emacs with Emacs Speaks Statistics.

Even as an emacs die-hard (very), I have not found yet a reason to move from the bundled editor for Mac that comes with R

RStudio is a pretty cool IDE for R.

I really like the "instant" auto-completion. Can someone throw light on how it was done?

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].

[1] https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/...

[2] https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/...

[3] http://docs.python.org/library/rlcompleter.html

[4] https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/...

That's very useful. I wish shells like bash/zsh had this instant auto-completion!

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.

I have had good experiences with ipython inside virtualenv, what's the problem?

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.

i thought you only needed to do that on a mac, on linux it seems to work fine with pip install ipython

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).

maybe the problem was that you need to do pip install -U ipython ?

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.

If you simply wish to access a virtualenv from your system ipython, you could do:

    with open('path/to/venv/bin/activate_this.py') as fh:
        exec(fh.read(), {'__file__' : fh.name})

Actually, having a %workon magic command for virtualenvwrapper[1] users seems like a useful thing. I think I'll write that ...

[1] http://pypi.python.org/pypi/virtualenvwrapper

There is: http://stackoverflow.com/questions/4806448/how-do-i-install-...

Wow, thanks a lot! I wonder why it's not in default somewhere.

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.

FYI for Windows users..."pip install bpython" won't work. You must install the Curses binary. I suggest from here: http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses

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. :)

You're complainimg to the wrong audience.

I rarely need Arabic bidi support in a shell, and if I do, I tend to copy paste from a proper text editor.

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.

What would make me use this is a way to get Django to use it when you launch `manage.py shell`, similarly to ipython.

One advantage over ipython I see here is that it doesn't use sqlite (I think), so it might run on Heroku.

Update: Django uses `bpython` by default if `ipython` isn't installed! Woohoo!

Yeah, I don't use Django so I never did this myself, but somebody kindly did the work for us. :)

using bpython has encouraged me to write more docstrings, which I previously did not do so much for personal projects ...

(because they are right there in the interpreter)

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.

[1] example: http://vimeo.com/22798433 (4 mins)

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)))
  )

That's the py-execute-line function, which is sending code to py-execute-region defined in python-mode (http://bazaar.launchpad.net/~python-mode-devs/python-mode/py...).

For some reason the default python mode in emacs is python.el rather than python-mode.el. So you probably want to start by using python-mode.

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?

Does BPython play nice with matplotlib/pylab yet? Last time I was very impressed with its functionality, but I could get it to draw a graph properly.

Fortunately, IPython, especially with the new --qtconsole, is also very very good.

I'll switch to bpython when it gets all the readline shortcuts that I use without even thinking (like alt-b, alt-f, alt-backspace, ctrl-c, etc.).

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.

I really like this: Add "import bpdb; bpdb.set_trace()" to your code, and from pdb type 'B' to drop into bpython.

Hmm, not bad. Actually, not bad at all. Very intuitive. I wish you could change the theme color though.

Yes you can change the colors. http://docs.bpython-interpreter.org/themes.html

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.

This is nice for just exploring Python (and modules).

this is awesome.

just got me ipython (a ~few minutes back), and bpython (like a ~minute back), and this feels damn awesome! I mean bpython!

Reply on news.ycombinator.com