ENH: select_dypes impl
State: closed

closes #7316

examples:

```
In [8]: paste
   df = DataFrame({'a': list('abc'),
                   'b': list(range(1, 4)),
                   'c': np.arange(3, 6).astype('u1'),
                   'd': np.arange(4.0, 7.0),
                   'e': [True, False, True],
                   'f': [False, True, False],
                   'g': pd.date_range('now', periods=3).values})
   df['h'] = df.g.diff()
   df['i'] = np.arange(3, 6).astype('u8')
   df['j'] = pd.date_range('20130101', periods=3).values
   df
## -- End pasted text --
Out[8]:
   a  b  c  d      e      f                   g      h  i          j
0  a  1  3  4   True  False 2014-06-22 23:40:53    NaT  3 2013-01-01
1  b  2  4  5  False   True 2014-06-23 23:40:53 1 days  4 2013-01-02
2  c  3  5  6   True  False 2014-06-24 23:40:53 1 days  5 2013-01-03

In [9]: paste
   df.select_type(include=[bool])
## -- End pasted text --
Out[9]:
       e      f
0   True  False
1  False   True
2   True  False

In [10]: paste
   df.select_type(include=['number', 'bool'], exclude=['unsignedinteger'])
## -- End pasted text --
Out[10]:
   b  d      e      f      h
0  1  4   True  False    NaT
1  2  5  False   True 1 days
2  3  6   True  False 1 days

In [11]: np.timedelta64.mro()  # this is an integer type
Out[11]:
[numpy.timedelta64,
 numpy.signedinteger,
 numpy.integer,
 numpy.number,
 numpy.generic,
 object]

In [13]: paste
   df.select_type(include=['object'])
## -- End pasted text --
Out[13]:
   a
0  a
1  b
2  c
```


Labels:
name: Enhancement
name: Dtype Conversions
description: Unexpected or buggy dtype conversions
name: API Design

Comments:
should not allow `ndim=1` and your indexer for `ndim>2` is not right, (its a bit tricky with Panels), as it depends on the orientation to figure out which dtype you'd be getting, so would just disallow anything but ndim==2 for now

Yep that's the wip part :)

I'll just implement on frame directly

This is a subtle issue. specifying `float` should match on the kind of the type rather than `==``

```
In [1]: np.dtype('float') == 'float32'
Out[1]: False

In [2]: np.dtype('float') == 'float64'
Out[2]: True

In [3]: np.dtype('float') == 'float'
Out[3]: True
```

need some tests with string dtypes too (and invalid ones I think you should raise), e.g. `datetime64[D]`. should raise, but `datetime` and `datetime64` I think ok (just because the first is TOO specific)

I check the dtype.type attribute if it's a subclass of the passed in dtype. All dtypes are converted using np.dtype before any checks occur 

whew jeez there are all sorts of dtype special cases

@jreback i think `'integer'` and `'int'` should mean different things to be consistent with numpy; i'm also not really too keen on `'numeric'` since that's not a dtype, but i'm allowing `'number'`

not sure i see the problem with `datetime64[D]` even tho we don't _really_ allow it

hows this coming?

Will get to it today. Work has picked up in the last week or so, haven't had as much time as I would like for pandas. :(

@jreback should empty include and empty exclude return an empty frame?

or how about a raise since that doesn't really make any sense

oh duh i'm already doing that nevermind

yeh I think you have to have either include or exclude non empty / not none

still could return empty frame of course

now disallowing `datetime64[D]` and others like it, i agree with you @jreback that it doesn't make sense ... allowing `ns` tho, since that's our main representation

you could allow thinks like

'datetime', 'date time', datetime.datetime, np.datetime

eg generic datetime dtypes (you may need to have a dict/regex matcher for things like this)

i'm already allowing `'datetime'`, `'datetime64'` and `'datetime64[ns]'`, in addition to the dtype form of the last two... i think that's enough.

ok cool

the one thing that's currently not possible is getting columns that are non string object dtypes

ie if you ask for object you'll always get strings as well as any other objects

no distinction between string and those anyhow (their could be but not now)

yeah ... not really worth the trouble.... that said, passing in `str` (and variations thereof) are going to return all object dtypes .... i think better to disallow `str` et al instead

there's really no sense in having one function that tries to hack around the `object`-ness of strings where the entire rest of the library's string handling is completely centered around them being `object`

I would just convert str to object (that's what read_csv and such does now) 

they r defacto the same and the it's easy to say include='str'
or include='numeric' (u accept this?)

i accept `number` which is the numpy super-dtype for all numeric values

if `str` is converted to object that will return all non string object types, eg bools with nan in them

sounds good 
maybe mention these in an example in doc string

i was trying to limit the variation and keep consistency with the numpy dtype hierarchy rather than fragment into another convention that's slightly different from numpy 

ok

hm so not clear tho on what you want to do with `str` ... i'm voting for a raise ie force users to pass `object` which is less surprising than getting back non string object columns when you pass in `str`

that's fine too

though we do accept str and just coerce to object elsewhere

we don't distinguish now

if in the future then could just change this

+0 so either way