[IPython-dev] cell magics

Jason Grout jason-sage@creativetrax....
Sat Feb 16 18:14:41 CST 2013


On 2/16/13 5:52 PM, Thomas Kluyver wrote:
> On 16 February 2013 23:19, Jason Grout <jason-sage@creativetrax.com
> <mailto:jason-sage@creativetrax.com>> wrote:
>
>     k=4
>     %timeit(runs=k) 2+3
>
>
> Give us some credit, that's already possible ;-)
>
> %timeit -r $k 2+3

Cool.  I didn't know that.  But if k was a list (for some other 
parameter), and you were trying to sub it in, you'd have to convert the 
list to a string, then convert it back in the decorator.  That's a 
little silly.


>
>     Using straight python instead of a custom string-based file format is
>     something I learned from IPython when you guys made your config files
>     actually just python files.  I find it somewhat ironic now that you are
>     arguing against making something more pythonic, and implicitly rejecting
>     the programmability and power of having a pythonic syntax :).
>
>
> For what it's worth, with hindsight, I'm not sure executable config
> files were such a great idea:
>
> - There's lots of reasons that we want config that we can modify from
> the program - to allow GUI configuration dialogs, or changing config
> from with something like the %config magic. There's no really good way
> to do that with an executable config file. If we write the new values
> into the file, we could be blowing away whatever logic the user already
> has there. If we store them separately, then sooner or later, the user
> finds a config value that doesn't appear to work, because it's
> overridden by a value somewhere else.
>
> - More generally, executable config files force you to have a full
> implementation of the language to load them. That's not such a problem
> for us, but I noticed with the xdg-user-dirs mechanism, you can only
> reliably access the information by running sh in a subprocess. Config in
> INI, JSON or even sqlite (like Firefox) can be accessed with a simple
> library.
>

Both good points!

-Jason



More information about the IPython-dev mailing list