[IPython-dev] Ascii imshow

[Nicolas Rougier]

Hi, 

Sorry for the delay, I was away from my mail.

After reading the commentaries, I realize there are still some work to do before the code can be properly integrated within IPython and I will try to make a nicer version as well as fully document it (using the template.py). For the git pull, I'm not very familiar with it and I don't know the proper command to pull or push, woudl yu have any pointer on this ?

For making the code to work with the QT console, it would require to parse the string sent to the console and interpret the ascii sequences. I did it some time ago for a gtk/ipython console but I'm not familiar at all with qt. (parsing code is of course available if one want to work on it).


As for the MPL terminal backend, it would be really cool (gnuplot got one) but I do have time right know to start such a thing.


Nicolas


On Feb 12, 2011, at 5:11 AM, Brian Granger wrote:

> Hi,
> 
> On Thu, Feb 10, 2011 at 12:43 PM, Fernando Perez <fperez.net at gmail.com> wrote:
>> On Thu, Feb 10, 2011 at 12:21 PM, Brian Granger <ellisonbg at gmail.com> wrote:
>>> * While I think this is incredibly cool, I am not sure this belongs in
>>> IPython.  Two reasons for this: i) it is useful for people outside of
>>> IPython and ii) plotting/viz is outside the scope of IPython.  I think
>>> a much better place for this would be a standalone module or
>>> matplotlib (imagine a terminal based backend!).
>> 
>> While I really hope MPL gets an ascii backend at some point, that's a
>> lot more work.  I don't know if Nicolas is up for it :)  I think it's
>> OK to have it in ipython in the sense that it's small, useful code for
>> terminal use.  While it's true that we're not in the data viz
>> business, we're in the business of making a really good interactive
>> environment, and the terminal is one of our strengths.
> 
> OK, if we do this, let make sure that:
> 
> * There are tests.
> * It is fully documented in docstrings.
> 
> I am mostly concerned about the fact that this type of stuff tends to
> get deposited with us to maintain in the future (like port to Python
> 3).  Ideally, these things would have maintainers that are committed
> to helping out with things.
> 
>> Something this small, left to live on its own, is much less likely to
>> get noticed/used than if we ship it and everyone benefits from it
>> right away.  I think of this as something much like our qt console
>> matplotlib support: something to seamlessly make ipython that much
>> better for heavy numpy/scientific users.
>> 
>>> * If it does go into IPython, the proper directory would be lib, not
>>> extensions.  IPython/extensions is for IPython extensions that adhere
>>> to the official IPython extension API.
>> 
>> Yes, my initial email was written with lib/, and then I backtracked
>> and thought of it as an extension.  But the api point is spot-on, so
>> lib it is.
> 
> Cheers,
> 
> Brian
> 
>> Cheers,
>> 
>> f
>> 
> 
> 
> 
> -- 
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com