BUG: Fix DataFrame.from_records w/ normal ndarray.

[jtratner]

I haven't looked at the from_records code before, which is why I'm spending all this time laying out a relatively minor change. Previously, was causing a TypeError about None not being iterable when arr.dtype.names was None. Now goes to 'last ditch' parsing instead.

This was the original test case (that dates back, in one form or another, to at least 2010), looked like this:

self.assertRaises(Exception, DataFrame.from_records, np.zeros((2, 3)))

Problem is that the actual Exception was a TypeError: None is not iterable-style exception, not something internal to the code. I changed this so now an ndarray that isn't structured (i.e., has arr.dtype.names is None) is treated separately from the structured ndarrays (so it goes into the general case 'last ditch' verison).

Now it basically produces the same thing as passing the array to the DataFrame constructor:

arr2 = np.zeros((2,3))
tm.assert_frame_equal(DataFrame.from_records(arr2), DataFrame(arr2))

[jreback]

looks good

this is basically a call to main constructor

ot: there is an issue out there for te reverse
eg main constructor should dispatch to from_records if either an ndarray has dtype.names or the dtype is a compound type

[jtratner]

okay - let's push that to a separate PR though.

[jreback]

agrees just fyi

[jtratner]

Well, this is the kind of thing that surfaces up when you clean up the Exception testing code (plus, it's a lot easier now that you can use assertRaises and assertRaisesRegexp as contextmanagers...makes it much easier to read).