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.

You can always install it directly, and not in a virtualenv. Am I missing something?

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.

Now I know what I missed.

That would require you to enable global site- packages for that virtualenv.

I can think of a few:

* awareness

* the official interpreter works quite well already

* yet-another-tool to learn

* You're in an interview and they don't have it.

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

It's also ugly when copy-pasted, which does not stop people exposing such ugliness on sites like Stack Overflow.

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.

People are working (or planning to work) on some of those:

* pip (sort of): http://www.python.org/dev/peps/pep-0439/

* virtualenv: already in Python 3.3

* requests: http://kushaldas.in/posts/notes-from-language-summit-at-pyco...

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.

Maybe in a restricted environment where you can't install it?

It's annoying to have to install Conda for a single program.

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.

The command line IPython does work with the PyPy interpreter.