Arguably better handling of input data in constructor for DataFrame (fix for #4297)
The problem was basically an odd restriction to `list` ,`tuple`, `dict`, or `numpy.ndarray` for data structure given as input to any constructor for DataFrame. Much cruder than a possible issue around buffer protocols I thought (the whole issue report went off on a tangent anyway ;-) ).

The source did not have much (any, actually) comments in that region, and I could not find unit tests documenting the behaviour, but I am guessing that the restriction stemmed from the fact that a string is a sequence in Python while the constructors should consider one string passed as data a scalar rather than a sequence.

The change made goes the other way around and accepts any sequence (not just `tuple`, `list`, or `numpy.ndarray`), except `str` or `unicode` (the later only applies to Python 2.x). `bytes` and `bytearray` are allowed (but I am not sure they should).

The pull request was tested (only `tests/test_frame.py` was run) on Python 2.7.4 and 3.3.1

fix for #4297 
 ok...you will need to hook up to travis (see contributing.md) and push again

also...use `com._is_sequence()` instead of your direct try: except around `len`
 @jreback : I can track `_is_sequence()` to be in `pandas/core/common.py`:

``` python
def _is_sequence(x):
    try:
        iter(x)
        len(x) # it has a length
        return not isinstance(x, basestring) and True
    except Exception:
        return False
```

I think that there is a (silent) possible issue with the logic at the following line:

```
19dc2847 (Wes McKinney     2012-11-18 23:59:31 -0500 1618)         return not isinstance(x, basestring) and True
```

(`and True` does not bring anything).
 @jreback 
Hook to Travis seems to be in place.
 @lgautier 

other thing is this is messing with the constructor, so need perf testing

`.test_perf -b <base_commit> -t <last commit of this PR>`

post (only care about > 1.15 ratio)...(some random things will appear, that's ok)
 @jreback 

Isn't this leaning a little toward hairsplitting ?

The only effective code difference is:

``` diff
-            elif isinstance(v, (list, tuple, np.ndarray)):
+            elif com._is_sequence(v):
```

the rest is comments, or editing the message string associated with raising exceptions when a problem occurs...
 @lgautier I think it would also be nice to incorporate #3478/#3479 in this same PR

and really no hurry on this....0.13 will be brewing for a while
 closing in favor of #4829
