[IPython-user] Feedback request on a new feature
fperez at colorado.edu
Mon Dec 22 15:38:57 CST 2003
Keith Beattie wrote:
>>the proposed syntax is:
> Seems kinda like bloat to me, but what about making ! a magic command? Then
> it is clearly an ipython thing (with no perly '$'s) and you could have the
> freedom to use whatever syntax or options you want (though I would stick with
> sh as much as possible). Something like
> @! [options] var_name=shell command
> Though how far would you want to go here? Would variable substitution be
> supported on the right of the '='? Could be a rat-hole of feature creep here...
Mmh, I kinda like this idea. A bit involved to code, but it can be done.
What do people think? It would allow for example solving the list/string or
print/quiet decisions via flags: I'd default to quiet+string, but a -l switch
could enable list splitting and a -v, verbose printing. I like it more and
I'm thinking of having it a magic called shv, short for shell variable (or
even sv?). This is a deliberately short name so it requires minimal typing,
and @! would be an alternate way to access it. It needs a 'real' magic name
anyway (you can't write a function called magic_! in python), and this also
allows you to access it without the @ sign if you have automagic on.
>>- Don't even print the output, it should just behave like getoutput().
>>People can print out the variable if they need it (esp. useful if the
>>output is potentially huge, but you want it trapped for processing).
> Yea, stick with the unix 'no news is good news' default on output.
>>- You should split the output and return a list, since that's what
>>people will want most of the time.
> Perhaps this could be an option of the magic command or set in ipythonrc.
Yup. As a magic, a simple -l switch could do. If people _really_ want it, I
could (in the rewrite) create a framework for people to set default flags for
any magic command they wish. Something like:
magic_NAME_default_flags = -l -v
would pass -l -v always to @NAME. This could be done with minimal effort as a
generic solution, not as a special case option. I already think that ipython
has too many special options, and this is not a good thing. But having an
option framework for the entire magic system is reasonable, especially since
people can just ignore it all if they wish.
>>I'd also like to know of anything else you may consider necessary for
>>the next release. At this point I have pretty much everything ready and
>>I'd like to move forward with releasing the code relatively soon. The
>>only things currently remaining in my mind are:
> Personally, I'd like to see ipython become better integrated with the
> debugger, or perhaps the other way around. There is probably many things I
> could currently do to make it better, that I just haven't discovered yet, so
> perhaps a 'debugging tricks' documentation section for us lazy people?
Well, I'm not sure what you have in mind. I did try once to get the pdb
prompt to have all the niceties of ipython (coloring, tab support, etc), but I
failed. Or did you have something else in mind? Keep in mind that this
attempt showed me that almost any 'real' integration beyond what exists would
almost require rewriting an entire pdb replacement with the ipython framework.
That's just too much for me (feel free to send the patches though ;)
As for better documentation, feel free (you or anyone else) to send in ideas
you have. I have a 'quick tips' section in the manual where I could include
these, and I'd be happy to do so.
Thanks for the feedback!
More information about the IPython-user