[IPython-dev] Function specific hooks into the ipython tab completion system

Tom Dimiduk tdimiduk at physics.harvard.edu
Thu Nov 29 09:38:13 EST 2012


That looks pretty great.  I would use something like that.

For the filename('.txt'), it could be handy to be able to pass arbitrary 
globs (as in for glob.glob).  You could still default to matching 
against the end of the string for extensions, but adding the glob 
support costs little (since you probably want to use glob internally 
anyway.

For extra (and unnecessary) fancyness, I could also see use cases for
from from tablib import tabcompletion, instance
class bar:
     pass
@tabcompletion(foo=instance(bar))
to be able to only complete for specific types of objects for other 
parameters (it would do an isinstance test).

Even more bonus points if the decorator could parse numpy styled 
docstrings to grab that kind of information about parameters.  I guess 
at this point you could do type checking, file existence checking, and a 
variety of other fun stuff there as well once you have that information, 
but that is almost certainly going out of the scope of your proposal.

Sorry if I am growing your proposal too much, the basic thing you 
proposed would still be very useful.  If I can grab some spare mental 
cycles, I would collaborate with you on it if you end up writing it.

Tom

On 11/29/2012 05:28 AM, Robert McGibbon wrote:
> Hi,
>
> Good spot, Matthias. I didn't see that method was already exposed -- I 
> was just looking at IPCompleter.matchers, which what that method 
> inserts into.
>
> Annotations are cool, but they're not obviously composable. I worry 
> that if I use them for this and then fix one syntax of how the 
> annotation is parsed, and somebody else
> is using annotations in their lib for something else, the two schemes 
> won't be able to interoperate. Also they're py3k only.
>
> My preferred syntax would be
>
> from tablib import tabcompletion, filename,
>
> @tabcompletion(fname=filename, mode=['r', 'w'])
> def load(fname, mode, other_argument):
>     pass
>
> or maybe with a parameterized filename to get specific extensions
>
> @tabcompletion(fname=filename('.txt'))
> def f(fname, other_argument):
>     pass
>
> Is this something that other people would be interested in?
>
> -Robert
>
> On Nov 29, 2012, at 2:02 AM, Matthias BUSSONNIER wrote:
>
>> Hi,
>>
>> I may be wrong, but IIRC you can insert your own completer in the 
>> IPython  completer chain and decide to filter the previous completion.
>>
>> You should be able to have a custom completer that just forward the 
>> previous completion in most cases,
>> And just do a dir completion if the object is np.loadtxt in your case 
>> (or look at __annotations__ if you wish).
>>
>> I've found one reference to inserting custom completer here
>> http://ipython.org/ipython-doc/dev/api/generated/IPython.core.interactiveshell.html?highlight=interactiveshell#IPython.core.interactiveshell.InteractiveShell.set_custom_completer
>>
>>
>> -- 
>> Matthias
>>
>> Le 29 nov. 2012 à 10:27, Aaron Meurer a écrit :
>>
>>> I've often thought this as well.  Probably a full-blown IPEP is in
>>> order here.  Perhaps __annotations__ would be the correct way to go
>>> here.
>>>
>>> Aaron Meurer
>>>
>>> On Thu, Nov 29, 2012 at 12:58 AM, Robert McGibbon 
>>> <rmcgibbo at gmail.com <mailto:rmcgibbo at gmail.com>> wrote:
>>>> Hey,
>>>>
>>>> Tab completion in IPython is one of the things that makes it so useful,
>>>> especially the context specific tab completion for things like 
>>>> "from ..."
>>>> where only packages, or obviously the special completion for 
>>>> attributes when
>>>> the line contains a dot.
>>>>
>>>> I use IPython for interactive data analysis a lot, and one of the most
>>>> frequent operations is loading up data with something like 
>>>> numpy.loadtxt()
>>>> or various related functions.
>>>>
>>>> It would be really awesome if we could annotate functions to 
>>>> interact with
>>>> the tab completion system, perhaps for instance saying that 
>>>> argument 0 to
>>>> numpy.loadtxt() is supposed to be a filename, so let's give 
>>>> tab-complete
>>>> suggestions that try to look for directories/files. Some functions only
>>>> files with specific extensions, so you could filter based on that or
>>>> whatever.
>>>>
>>>> By hacking on the code for completerlib.py:cd_completer, I sketched 
>>>> out a
>>>> little demo of what you could do with this: 
>>>> https://gist.github.com/4167151.
>>>> The architecture is totally wrong, but it lets you get behavior like:
>>>>
>>>> ```
>>>> In [1]: ls
>>>> datfile.dat  dir1/        dir2/        file.gz      random_junk 
>>>>  test.py
>>>>
>>>> In [2]: directory_as_a_variable = 'sdfsfsd'
>>>>
>>>> In [3]: f = np.loadtxt(<TAB>
>>>> datfile.dat  dir1/        dir2/        file.gz
>>>>
>>>> In [4]: normal_function(<TAB>
>>>> Display all 330 possibilities? (y or n)
>>>>
>>>> In [5]: g = np.loadtxt(di<TAB>
>>>> dict                      dir1/ 
>>>>                     directory_as_a_variable
>>>> divmod
>>>> dir                       dir2/ 
>>>>                     directory_of_my_choosing
>>>> ```
>>>>
>>>> Basically hitting the tab completion, when np.loadtxt is on the 
>>>> input line,
>>>> only shows directories and files that end with a certain extension. 
>>>> If you
>>>> start to type in the name of an object in your namespace, it'll 
>>>> show up too,
>>>> but only once you've typed in more than 1 matching character.
>>>>
>>>> The implementation in my gist is pretty lame. The way I've coded it 
>>>> up, the
>>>> special behavior is based on simply finding the string "np.loadtxt" 
>>>> on the
>>>> input line, not on the actual function. This means you can't really 
>>>> make the
>>>> behavior specific to your position in the argument list (i.e. I 
>>>> know that
>>>> the first arg is a filename, and so should be tab completed like 
>>>> this, but
>>>> the other ones are not). I suspect the right way to do the 
>>>> implementation is
>>>> via function decorators to specify the behavior and then adding to
>>>> IPCompleter instead.
>>>>
>>>> I think I'm up for giving this a shot.
>>>>
>>>> Thoughts? Is this a feature anyone else would find interesting?
>>>>
>>>> -Robert
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> IPython-dev mailing list
>>>> IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>>>
>>> _______________________________________________
>>> IPython-dev mailing list
>>> IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org <mailto:IPython-dev at scipy.org>
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20121129/95de32dd/attachment.html>


More information about the IPython-dev mailing list