One problem with tab completion is that you can no longer paste tab-indented snippets into the intepreter, or use tab to indent code you're typing. I put the following in my python startup file to fix the issue:
import readline, rlcompleter
readline.parse_and_bind("tab: complete")
readline.parse_and_bind('bind ^I rl_complete')
class MyCompleter(rlcompleter.Completer):
def complete(self, text, state):
if text.lstrip() == '':
if state == 0:
return text + '\t'
else:
return None
else:
return rlcompleter.Completer.complete(self, text, state)
readline.set_completer(MyCompleter().complete)
Wow, it's about time. It's not that hard to set up tab completion using a startup script, but that always struck me as sort of a backwards thing to have to do every time I set up a new server or workstation.
The thing that soured me on bpython, after loving it for months, was the realization that I could not scroll back easily to see results of past things (aside from the most recent one). Ipython (and, even better, the qtconsole for it) does that much better.
In a console, I like bpython's interface and autocomplete suggestion interface, but being unable to scroll back and see what I did 3 commands ago was a deal killer.
I had the same feeling about IPython, and I rather liked bpython — and then I discovered DreamPie, which offers a number of features I have found useful in exploratory programming. Yes, it moves me out of both Emacs and my terminal, but it's almost worth it.
I use virtualenv for all projects, and frequently destroy and recreate virtualenvs. iPython takes a good while to install; doing it over and over again in fresh virtualenvs gets to be a chore, so I tend to do it only when I really need it.
I dunno, is there a better way, maybe installing iPython globally, but rewriting the shebang line to use /usr/bin/env python?
A global installation of IPython now recognises if you start it with a virtualenv active, and adds the virtualenv to sys.path so that you can import modules installed there.
It isn't limited to packages in the virtualenv - that is, it always behaves like you created the virtualenv with system-site-packages enabled, because it is importing its own modules from there. But for most interactive use, that's not a problem.
AFAIK if you're using virtualenvs, you'd best bet would be various approaches to caching/proxying pypi. Won't help if the actual install (compile) times of ipython is a problem though.
If it's installed globally then it wont have access to the libraries installed only in the virtualenv. I think there's a way to work around this, but I haven't taken the time to look into it.
This should be fixed in the latest iPython versions. iPython is now virtualenv-aware -- it'll add your venv path at startup even if iPython is installed in global site-packages.
The ipython interaction trace seems to run counter to the grain of doctest/docstring. I frequently copy and paste standard interactive sessions into a file to act as docstring exemplars or immediate doctest content for cross-platform/cross-version compatibility checking. I couldn't see how to do that with published ipython session output. Is it just a matter of changing the ipython prompt or is it a more fundamental issue?
You can always use `%doctest_mode` to toggle back and forth between IPython-style prompts and `>>>` ones (along with changing exception mode to be more standard-looking).
Yeah, iPython already has tab completion, and everyone is still free to use it. It has plenty of great additional features, too!
Everyone is talking about reasons why using iPython can be impractical, or cumbersome/not-possible to install, but the important thing is that the default experience should strive to be the best experience.
Python has a pretty good standard library, and a pretty good batteries-included toolset, but talk to anyone who's experienced in it and you'll hear about all the Best Tools you have to install in order to be up to par: pip, virtualenv, ipython, third-party libraries to supplement what you want to do (requests, *-parse...).
When the community agrees that there are certain extras that are all good to install, it shows that the features they offer should probably be provided by default. I like Python, and I want Python to provide the best experience by default.
As for IPython, many would agree it's not suitable for inclusion, which is not necessarily a bad thing. That does not stop anyone from stealing some of its features for inclusion in the default interactive interpreter though.
There are two reasons that I can think of that I have experienced. First, IPython simply doesn't behave like standard Python; you can have very obscure corner-case bugs in otherwise-normal code because of its magic. Second, if you're using PyPy, you don't get to use IPython.
Edit: I meant that PyPy isn't compatible with most of the things people use IPython for, like Numpy and Scipy, not that IPython's shell doesn't work on PyPy. Sorry.
I've always wondered why so many of these usability niceties have been available yet neglected soooo long, while the language as a whole has progressed so much? There are plenty more of these, like interpreter history and adding pip to the stdlib.
On Windows it's even worse, newbies have to figure out how to get it in their path and hunt-down important libraries.
The mystery goes away once you start reading python-dev and watching bugs.python.org... people find it hard to agree on the right way to do things. It takes a lot of energy for the bigger changes to go in, and many of those with the energy are busy working on other things, while the Issues rot. CPython needs more contributors (as does so many volunteer software projects).
You have a better chance of success if you try. Even respected core developers, including Guido himself, fail to get stuff they want in. So, no, it's no guarantee.
I don't remember the last time I used anything except iPython. I use EC2 a lot, and the first thing I do after firing an instance is install ipython, even if I don't intend to use the instance for python related stuff at all.
There is a recent PEP excluding IDLE from this policy, allowing it to get usability improvements on older pythons. One could think that enabling completions is a similar usability fix (though one change isn't worth the arguing to get exception) but in fact this change required a new var in `sys` and changed site.py, both unacceptable for a minor release.
That's even for backport to 3.3. As for 2.7, even when when allowed, most changes aren't backported to it simply because the code has diverged a lot and core devs are tired of implementing changes twice.
