[IPython-dev] Using argparse for %magics

[Fernando Perez]

Howdy,

On Fri, Apr 10, 2009 at 10:54 PM, Prabhu Ramachandran
<prabhu at aero.iitb.ac.in> wrote:
> On 04/07/09 23:41, Fernando Perez wrote:
>>
>> On Sun, Apr 5, 2009 at 1:50 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>>
>>> I have updated my personal collection of %magics today:
>
> [...]
>>
>> Just an initial reply before we dive into this, since I'm going
>> semi-offline for a couple of days.
>>
>> +1 to argparse for this, as long as we carry it (not as a separate
>> dependency).  I've been thinking about cleaning up the magics as part
>> of the core reorg Brian will work on soon, and this would fit nicely
>> into that idea.
>
> Just my vote that it would be nice if these (the print_traits esp.) were
> available in the standard IPython.

Yup.    BTW, I meant 'as long as we continue to carry argparse
ourselves', I was just clarifying that I'm happy to use it for the
long haul...

> I also have a suggestion regarding magics in general.  I always found
> IPython's timeit *much* more convenient than the standard timeit module.
>  However, IPython's timeit is only usable from IPython and not from a
> standalone Python script.  I think all magics (that are of use outside of
> IPython) ought to be refactored to be usable outside of the interactive
> IPython shell.

Absolutely!  I have a draft blueprint on my drive about magics, that's
something that I hope we'll revisit very soon, as Brian makes headway
into the core reorganization.  What I hope we'll have is that the
actual magics will be simple callable objects that can be instantiated
and used anywhere, with the % syntax being just a bit of interactive
sugar.  In addition, I hope most  of them will be very thin wrappers
around regular functions and objects in the ipython library of
utilities that can be used without ipython itself running.

Some only make sense if ipython is active, and they will need an
actual ipython at startup.  Many others will actually be called *by*
ipython but can be equally used on their own.

I'm going to think a bit more about this spec and post it later...

>
> I also think I have found a little bug(?) in the timeit magic
> implementation.  Here is a patch (this is off the 0.9.1 release):
>
> --- Magic.py.orig       2009-04-11 11:14:49.000000000 +0530
> +++ Magic.py    2009-04-11 11:15:15.000000000 +0530
> @@ -1815,9 +1815,9 @@
>             # determine number so that 0.2 <= total time < 2.0
>             number = 1
>             for i in range(1, 10):
> -                number *= 10
>                 if timer.timeit(number) >= 0.2:
>                     break
> +                number *= 10
>
>         best = min(timer.repeat(repeat, number)) / number
>
> The rationale is as follows.  Lets say you have a function that takes 2
> seconds to evaluate.  With the original code you are going to run that
> function 10 times regardless of the fact that it already takes 2 seconds and
> with the original code, timing this will take at least 60 seconds (with
> repeat=3) which is way too much.  Here is a simple test case:

Many thanks!  This has bothered me more than once but I'd never taken
the time to track it down, that's great.

I pushed it to my trunk, this will make its way into 0.10 (any day now :)

Cheers,

f