Issue #341: "RunTime error when printing astropy.table.Table row"

[jwoillez]

First commit is a test case that fails.
Second commit is a workaround.
Fundamental issue is at: numpy/numpy#385

[eteq]

Thanks for looking into this, @jwoillez - just as an FYI, you can attach PRs directly to issues you create instead of issuing a separate PR. You can either use a script I made for this (https://gist.github.com/1750715) or if you have the hub command line tool (http://defunkt.io/hub/) installed, it's pull-request command will do this.

(It's also fine to issue a separate PR - just wanted to mention that you can do this also)

[jwoillez]

It indeed felt awkward open in a separate PR. Thanks @eteq for the interesting pointers. On the learning curve...

[astrofrog]

This seems fine to me, but I'll let @taldcroft make the final call

[taldcroft]

@jwoillez - thanks for working on this and sorry for the slow response. I'll look at this today. Everything looks good, I just want to first actually reproduce the issue and take a quick look to satsify myself that the numpy bug should not be a problem anywhere else. Also, I'll run this through my stage branch to do the full regression test on all platforms before merging (if you or @astrofrog haven't done so).

[taldcroft]

Looks good and passes on jenkins for debian and OSX. I'm merging now.

[astrofrog]

@taldcroft - I just noticed, the test is failing on Windows. Any ideas?

https://jenkins.shiningpanda.com/astropy/job/astropy-winxp32-multiconfig/COMPILER=mingw32,NUMPY_VER=numpy-1.6.0,PYTHON_VER=python-2.6/16/testReport/astropy.table.tests.test_row/TestRow/test_format_row/

[taldcroft]

Now we're playing whack-a-mole. It looks like the windows repr of an int array is (1L, 4L) instead of (1, 4) as in linux and mac. We could update the test so it just checks that no exception is raised. Replace

assert format(row, "") == "<Row 0 of table\n values=(1, 4)\n dtype=[('a', '<i8'), ('b', '<i8')]>"

with

format(row, "")

or maybe

assert format(row, "").startswith("<Row 0 of table")

These latter two versions should still exercise the original bug.

[astrofrog]

I like the last one, because it only depends on astropy.table rather than Numpy (i.e. if Numpy change their string representation of an array, we have to update the text).

Do you want me to fix it? I'm happy to, but just want to make sure we don't both do it.

[taldcroft]

Yes, please fix this. Thanks.

[astrofrog]

Should be fixed in b7da66c

[astrofrog]

Just confirming the tests now pass on Windows