[IPython-dev] Ascii imshow

Fernando Perez fperez.net at gmail.com
Sun Feb 13 16:29:29 EST 2011


Hi Nicolas,

On Sun, Feb 13, 2011 at 4:37 AM, Nicolas Rougier
<Nicolas.rougier at inria.fr> wrote:
> Thanks, the guide has been very helpful (I opened a bug report for a small typo).

Glad to hear that, and thanks for filing the report; Thomas already
jumped on it and the online guide should be soon updated once Thomas
sets his environment to do the gh-pages pushes (up until now only Min
and I had been pushing).

> If I did thing properly, here is the summary:
> https://github.com/rougier/ipython/compare/master...ascii_imshow

Excellent!  I would suggest that you now simply click on the 'Pull
Request' button so we can review your contribution for merge.  It's
likely to go through a few more iterations before it's merged, but
once in a pull request, we have a nice centralized location for the
discussion, you can keep fine-tuning it, and when ready it will go in
cleanly.

> I added the possibility to display MxNx3 (RGB) or MxNx4 (RGBA) since the code is quite similar. There is no test yet since I'm not sure how to test such a visual thing.

Great features.

The topic of testing is very important, so I want to address this in
some detail, hopefully this will be useful to others as well.

You are indeed correct that testing something visual is tricky.  The
point is to realize that printing is a side effect, and testing side
effects is in general quite hard.  But you can think of printing as a
two-step process: a) computing the string to be printed b) actually
sending that string to the terminal.  While b) more or less can only
be checked interactively by a human, a) can be automatically
validated.

Basically, when thinking of testing, you want to code so there's a
clean separation between the functional computation and the part that
does purely the side effects.  That is, instead of:

def show_foo(x):
  print 'abc', x, 'pqr'

you would do

def compute_foo(x):
  return 'abc %s pqr' % x

def show_foo(x):
  print compute_foo(x)

That way at least compute_foo(x) can be fully tested in a 100%
functional way.  And then a test can also be written for show_foo()
just to ensure it doesn't crash (so that any api changes in
compute_foo are correctly caught also in show_foo), but that test
doesn't need to actually validate the output.  In simple cases it may
(such as with a doctest), but in others it may be hard, like in your
situation.

Let me know if this helps.  If it's clear enough, we'll add it to the
dev guidelines in the testing section.

> I also tried to detect terminal number of colors using curses (if available) because I don't know if IPython already got some terminal capabilities related functions (mainly, size and number of colors).

No idea on that front, sorry.

Many thanks for your willingness to follow the (hopefully
straightforward) process!  We're really glad to have more
contributions to the project, and I'm excited to start seeing things
going more smoothly on this front.

Best regards,


f



More information about the IPython-dev mailing list