👍 , as this addresses one of the main reasons in my head for #729

I think this could easily be done already - even if we don't do everything done in #664, just this would already be useful. With the new API, we could even do:

t['a'] = np.array([1,2,3]) * u.m

and the unit would get auto-set. Note, we don't have to yet decide whether accessing a column returns a Quantity, but at least for now the above behavior should be unambiguous.

@taldcroft @eteq - I attached code that does this, but we should discuss the behavior a little more. With this patch:

In [5]: from astropy import units as u

In [6]: from astropy.table import Table

In [7]: import numpy as np

In [8]: t = Table()

In [9]: t['a'] = np.array([1,2,3]) * u.m/u.s

In [10]: t['a']      
Out[10]: 
<Column name='a' unit='m / s' format=None description=None>
array([1, 2, 3])

In [11]: from astropy.table import Column

In [12]: c = Column(np.array([1,2,3]) * u.km / u.yr)

In [13]: c
Out[13]: 
<Column name=None unit='km / yr' format=None description=None>
array([1, 2, 3])

Note that if the unit is explicitly specified, then the behavior is to convert the quantity to that unit:

In [14]: c = Column(np.array([1,2,3]) * u.km / u.yr, unit=u.m/u.s)

In [15]: c
Out[15]: 
<Column name=None unit='m / s' format=None description=None>
array([  3.16880878e-05,   6.33761756e-05,   9.50642634e-05])

Now this should be made consistent with whatever Quantity and things like Angle do in the end (there was some discussion ongoing for the Angle behavior).

@astrofrog - I think this looks very good! And it seems logical to make the behaviour the same as for Quantity (note that the discussion about Angle was mostly about what to do with a string that implied a unit inconsistent with the unit given).

But why is one test commented out?

@mhvk - oops, fixed now :)

@taldcroft - can you review this? (and merge if happy with it?)

@astrofrog - OK will look at this.

The code and tests look good. Seems like it would be worth putting in an example in the sphinx Table docs. It's a cool feature that might not be obvious to people.

@astrofrog @mdboom @mhvk - slightly OT, but we've been talking about Table columns and Quantity. I wonder if we could do something easy in the short term and allow a Table column with units to initialize a Quantity:

t = Table.read('my_table_with_units.dat', ..)  # velocity column with m/s unit
velocity = Quantity(t['velocity'])  # correctly gets unit of m/s

One might also do velocity = t['velocity'].as_quantity(), but to me the first one seems cleaner since it doesn't require a new method and is more future-proof.

[EDIT: I didn't check if this already works...]

@taldcroft - no, this did not yet work, but should. Just make a sample implementation...

@astrofrog - while making that sample implementation, I went the duck-type route and I wondered whether one shouldn't do the same here. I.e., check whether the input has a unit attribute and a to method or so.

@taldcroft - it this looks ok, and Travis passes, shall I merge this? (I added some documentation and an entry in CHANGES.rst)

@mhvk - I'm not too comfortable with the duck-typing, hence why I left it as-is. But if other people also agree duck-typing is the way to go then we can do that.

@astrofrog - no problem, I think this is not particularly important for this issue. But once the integration of the packages becomes tighter, it will become useful to think that defining characteristics each have, and work with those rather than isinstance so that integration with other python packages is easier.

@astrofrog - looks great, I went ahead and merged it.

Thanks @astrofrog and @taldcroft - with this I think my original complaint from way back in #729 is resolved, and now I have no right to ever again complain about creating columns! :)