5 ms·

This is great, but is there any reason whatsoever not to use ipython?

by dmd 14y ago

sigzero 14y ago
Maybe in a restricted environment where you can't install it?
tshepang 14y ago
I can think of a few: * awareness * the official interpreter works quite well already * yet-another-tool to learn
- a3n 14y ago
  * You're in an interview and they don't have it.
aaronharnly 14y ago
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?
- tshepang 14y ago
  You can always install it directly, and not in a virtualenv. Am I missing something?
  - xnxn 14y ago
    That would require you to enable global site- packages for that virtualenv.
  - Buttons840 14y ago
    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.
    - tshepang 14y ago
      Now I know what I missed.
    - eclipticplane 14y ago
      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.
- e12e 14y ago
  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.
- takluyver 14y ago
  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.
MostAwesomeDude 14y ago
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.
- freyrs3 14y ago
  The command line IPython does work with the PyPy interpreter.
gjhiggins 14y ago
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?
- tshepang 14y ago
  It's also ugly when copy-pasted, which does not stop people exposing such ugliness on sites like Stack Overflow.
- fperez_org 14y ago
  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).
cpdean 14y ago
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.
- tshepang 14y ago
  People are working (or planning to work) on some of those: * pip (sort of): http://www.python.org/dev/peps/pep-0439/ http://www.python.org/dev/peps/pep-0439/ * virtualenv: already in Python 3.3 * requests: http://kushaldas.in/posts/notes-from-language-summit-at-pycon.html 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.
scott_karana 14y ago
It's annoying to have to install Conda for a single program.

This is great, but is there any reason whatsoever not to use ipython?

by dmd 14y ago

This is great, but is there any reason whatsoever not to use ipython?

sigzero 14y ago

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

tshepang 14y ago

I can think of a few: * awareness * the official interpreter works quite well already * yet-another-tool to learn

a3n 14y ago
* You're in an interview and they don't have it.

aaronharnly 14y ago

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?

tshepang 14y ago
You can always install it directly, and not in a virtualenv. Am I missing something?
- xnxn 14y ago
  That would require you to enable global site- packages for that virtualenv.
- Buttons840 14y ago
  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.
  - tshepang 14y ago
    Now I know what I missed.
  - eclipticplane 14y ago
    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.
e12e 14y ago
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.
takluyver 14y ago
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.

MostAwesomeDude 14y ago

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.

freyrs3 14y ago
The command line IPython does work with the PyPy interpreter.

gjhiggins 14y ago

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?

tshepang 14y ago
It's also ugly when copy-pasted, which does not stop people exposing such ugliness on sites like Stack Overflow.
fperez_org 14y ago
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).

cpdean 14y ago

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.

tshepang 14y ago
People are working (or planning to work) on some of those: * pip (sort of): http://www.python.org/dev/peps/pep-0439/ http://www.python.org/dev/peps/pep-0439/ * virtualenv: already in Python 3.3 * requests: http://kushaldas.in/posts/notes-from-language-summit-at-pycon.html 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.

scott_karana 14y ago

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