[IPython-dev] Ascii imshow

[Brian Granger]

Fernando,

Do you think it would make sene to implement this as an object that
has special print methods like __pretty__, __png__, etc.  That would
make it super easy to add support for other frontends.

Cheers,

Brian

On Sat, Feb 12, 2011 at 1:32 AM, Nicolas Rougier
<Nicolas.rougier at inria.fr> wrote:
>
> 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
>
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com