Do not copy info when getting scalar Time item - #10889

The PR looks OK, but I'm still wondering whether it is the right approach: the following behaviour seems weird to me:

import numpy as np
from astropy.time import Time
from astropy.table import Table
t = Table([Time(np.arange(50000, 50010), format='mjd')], names=['t'])
t.add_index('t')
cx = t['t'][3:4]
cx.info.indices
[   t    rows
 ------- ----
 50000.0    0
 50001.0    1
 50002.0    2
 50003.0    3
 50004.0    4
 50005.0    5
 50006.0    6
 50007.0    7
 50008.0    8
 50009.0    9]
# Yet
cx.info.parent_table
# gives None

Why would a sliced time still have the full index associated with it?

In contrast, I can see the logic of

tx = t[3:4]
tx['t'].info.indices
[Index slice (3, 4, 1) of
    t    rows
 ------- ----
 50000.0    0
 50001.0    1
 50002.0    2
 50003.0    3
 50004.0    4
 50005.0    5
 50006.0    6
 50007.0    7
 50008.0    8
 50009.0    9]
tx['t'].info.parent_table
<Table length=1>
   t   
 object
-------
50003.0

I guess I wonder if indices should be omitted if the column is sliced; it looks like this would work fine, since the table already takes care of updating it if it is the table rather than the column that is sliced.

The advantage of solving it at the table level would be that the same solution would work for all other possible mixin columns too.

I think I've got an alternative, I think - see #10890

Moving discussion here about whether this is still needed given #10890. I can see the argument in #10890 (comment) that

for a scalar getitem I really think we don't want to copy info at all. For instance, the info attribute can have meta, and that might be a 5-megabyte structure. I just confirmed that a scalar getitem makes a deepcopy of that meta (in master and in this PR), so doing np.array(tm) (where tm is a large array-valued Time object with a big info.meta) will explode memory again.

Since this would hold also for SkyCoord, Quantity, etc., I think we'd need to do the same things for those, which suggests involving info itself in the decision about what would need to be copied. E.g., in the mechanism for DataInfo.__set__ one could add a check on its parents shape and do nothing if that shape was ():

Note that we struggled a bit with this before - see #5047. I think the conclusion there was a good one: we should have clear, predictable behaviour...

p.s. Another possibility for implementation is to use that for most classes any subsetting, etc., goes through _apply() - we could change that to call a new, to-be-defined DataInfo._apply - that would allow including information about what is being done. But probably overkill.

Since this would hold also for SkyCoord, Quantity, etc., I think we'd need to do the same things for those, which suggests involving info itself in the decision

Good plan. The question is whether this should only apply to the BaseColumnInfo class or DataInfo itself. I'm hesitant about extending this behavior change outside of tables. For BaseColumnInfo I just tried this out and it passes the new test in this PR (after reverting the change in time/core.py):

    def __set__(self, instance, value):
        # For Table columns do not set `info` when the instance is a scalar.
        try:
            if not instance.shape:
                return
        except AttributeError:
            pass

        super().__set__(instance, value)

Nice! I think I agree that it makes most sense to do it to BaseColumnInfo, since then a class that uses it has more or less explicitly signed up for making itself work with Table - and for Table's Column, scalars also have no connection to the table any more.

@mhvk - this should be ready for review.

p.s. Really like the detailed and thorough tests!