Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IPython should prioritize __all__ during tab completion #70

Closed
ipython opened this issue May 10, 2010 · 3 comments
Closed

IPython should prioritize __all__ during tab completion #70

ipython opened this issue May 10, 2010 · 3 comments
Milestone

Comments

@ipython
Copy link
Collaborator

ipython commented May 10, 2010

Original Launchpad bug 462648: https://bugs.launchpad.net/ipython/+bug/462648
Reported by: dholth (Daniel Holth).

When exploring an api with tab completion, it is sometimes useful to distinguish between the public interface (names intended for use) and the implementation (unrelated imported modules, double underscore names and so on).

IPython could help, with minimal implementation difficulty, by putting names in all first during tab completion. For example,

import urllib
urllib.
urllib.ContentTooShortError urllib._localhost urllib.quote
urllib.FancyURLopener urllib._noheaders urllib.quote_plus
urllib.MAXFTPCACHE urllib._nportprog urllib.reporthook
urllib.URLopener urllib._passwdprog urllib.socket
urllib.all urllib._portprog urllib.splitattr
urllib.builtins urllib._queryprog urllib.splithost
urllib.class urllib._safemaps urllib.splitnport
urllib.delattr urllib._tagprog urllib.splitpasswd
urllib.dict urllib._thishost urllib.splitport
urllib.doc urllib._typeprog urllib.splitquery
urllib.file urllib._urlopener urllib.splittag
urllib.format urllib._userprog urllib.splittype
urllib.getattribute urllib._valueprog urllib.splituser
urllib.hash urllib.addbase urllib.splitvalue
urllib.init urllib.addclosehook urllib.ssl
urllib.name urllib.addinfo urllib.string
urllib.new urllib.addinfourl urllib.sys
urllib.package urllib.always_safe urllib.test
urllib.reduce urllib.basejoin urllib.test1
urllib.reduce_ex urllib.ftpcache urllib.thishost
urllib.repr urllib.ftperrors urllib.time
urllib.setattr urllib.ftpwrapper urllib.toBytes
urllib.sizeof urllib.getproxies urllib.unquote
urllib.str urllib.getproxies_environment urllib.unquote_plus
urllib.subclasshook urllib.localhost urllib.unwrap
urllib.version urllib.main urllib.url2pathname
urllib._ftperrors urllib.noheaders urllib.urlcleanup
urllib._have_ssl urllib.os urllib.urlencode
urllib._hextochr urllib.pathname2url urllib.urlopen
urllib._hostprog urllib.proxy_bypass urllib.urlretrieve
urllib._is_unicode urllib.proxy_bypass_environment urllib.warnings

If I'm using the library, I don't care that urllib.py imports 'os'. Instead, why not show something more like:

urllib.
all: ['urlopen', 'URLopener', 'FancyURLopener', 'urlretrieve', 'urlcleanup', 'quote', 'quote_plus', 'unquote', 'unquote_plus', 'urlencode', 'url2pathname', 'pathname2url', 'splittag', 'localhost', 'thishost', 'ftperrors', 'basejoin', 'unwrap', 'splittype', 'splithost', 'splituser', 'splitpasswd', 'splitport', 'splitnport', 'splitquery', 'splitattr', 'splitvalue', 'getproxies']

everything else, or everything including all names:
(from above)

@ipython
Copy link
Collaborator Author

ipython commented May 10, 2010

[ LP comment 1 by: Fernando Perez, on 2010-04-25 22:08:23.288272+00:00 ]

Unfortunately I don't think that's possible, at least with readline. Readline uses a callback interface and expects only a list of completions. The printing/formatting of the completions is done by readline, not by us, and in a list there is no way of specifying what comes from where.

This would be possible, and it's a good idea, for more sophisticated guis that manage their own completion. I'm marking it as a wishlist so we keep it in mind moving forward, though at the terminal I'm afraid we're limited by readline's design.

Thanks for the idea.

@takluyver
Copy link
Member

We now only show the "public" methods (which don't start with _) by default. Is this satisfactory? Do we want to leave this open for the alternative frontends?

@fperez
Copy link
Member

fperez commented Apr 15, 2012

Closed by #1529, just merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants