Enable tab-completion in the interactive interpreter by default(hg.python.org)
hg.python.org
Enable tab-completion in the interactive interpreter by default
http://hg.python.org/cpython/rev/d5ef330bac50
54 comments
To use tab completion in earlier Python versions:
To make it seamless, put those lines in ~/.pythonrc and add this to your zshrc
export PYTHONSTARTUP="$HOME/.pythonrc"on OSX you need
readline.parse_and_bind('bind ^I rl_complete')I use a combination of all these 3 tricks as I have my dotfiles shared between Mac and Linux.
Basically my pythonstartup.py contains the extra check for os:
Basically my pythonstartup.py contains the extra check for os:
AP_AUTOCOMPLETE=False
import sys
try:
import readline
except ImportError:
print "Module readline unavailable"
else:
import rlcompleter
readline.parse_and_bind("tab: complete")
if sys.platform == 'darwin':
readline.parse_and_bind("bind ^I rl_complete")
AP_AUTOCOMPLETE=TrueOne 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)Niiiice!
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.
Tangentially related: Shell tab completion for Python programs using argparse: https://github.com/kislyuk/argcomplete
I always wondered why default interpreter can't be more like bpython.
Good work
Good work
Some would argue why it can't be more like IPython. :)
But agreed, good work... tab completion is very helpful when learning a language.
But agreed, good work... tab completion is very helpful when learning a language.
IPython seems to be "too heavy" for me compared to Bpython :)
Bpython is perfect for me.
Bpython is perfect for me.
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.
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.
This is great, but is there any reason whatsoever not to use ipython?
It's annoying to have to install Conda for a single program.
Maybe in a restricted environment where you can't install 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?
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.
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.
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.
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.
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.
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.
* 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.
The related Issue has been open since 2009: http://bugs.python.org/issue5845.
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.
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).
BTW, are you implying/do you think I could get some of these in with some enthusiasm and a bit of work (given they've been implemented for a decade).
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.
Hmm, they might take a cue from the Active State distribution, who has done a lot of things right.
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.
Will this be on 2.7.x or just 3.x?
3.4, early next year http://www.python.org/dev/peps/pep-0429
Is there anything that would prevent this from being backported to 2.x.x ?
None of the releases deemed final accept any new features. It's general release policy for any FLOSS project, and only neglected on rare occasions.
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.
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.
politics
[deleted]