This is very exciting! I will try and take a look.

This looks like a problem:

In [40]: t
Out[40]: 
<Table length=3>
  a      b     c  
int32 float32 str1
----- ------- ----
    3     3.0    e
    2     2.0    d
    1     1.0    c

In [44]: t.insert_row(2, (10, 10.0, 'z'))

In [45]: t
Out[45]: 
<Table length=4>
  a      b     c  
int32 float32 str1
----- ------- ----
    3     3.0    e
    2     2.0    d
   10    10.0    z
    1     1.0    c

In [46]: t.indices
Out[46]: [[[ 1  2  3 10], [2 1 0 2]]]

Does anyone have any thoughts about the best way to support indices for mixin columns? The issue is that indices are stored and managed in the Column class, so mixin indices will require a workaround--maybe we should store mixin indices directly in Table? I can't think of a clean way to update indices based on mixin column modifications, though, unless we change mixin classes directly.

The first thought that comes to mind for mixins is to put the indices into the info container. That is the new generic easy to handle attributes in a mixin safe way. What do you think?

Makes sense to me, although the real issue is that indices have to be updated every time a column is modified. For example, t['col'][row] = val should update all indices in t['col']. This functionality is currently built into Column but the fact that mixins can be essentially arbitrary makes it more difficult.

@mhvk - this table indexing PR is touching on the whole mixin concept and you might have some ideas. See the comments above about indexes and mixins. One idea is to use some kind of mixin class (here "mixin" in the traditional sense) like SupportsTableIndexing to indicate that a mixin like Quantity has the machinery in __setitem__ to handle in-place updates. Another idea is a class attribute like supports_table_indexing = True. The latter is perhaps simpler. I haven't tested to see which is faster.

[EDIT: SupportsTableIndexing would be on the info object, not the parent object!]

@mdmueller - for the canonical case of Time objects (for Time series) we are helped by the fact that Time objects are immutable and you cannot set them. For at least this case there is no problem. But of course we will want to index Quantitys.

Was just going to comment we could have the mixin on the info object by an attribute, or, perhaps easier, by a subclass that provides the required index -- but I see you edited your comment to say the same thing!

What about naming the index_modes as freeze (instead of modify) and discard_on_copy instead of copy. The current names seem to be exactly opposite of what I would expect.

Sounds good -- I'll update the names.

Can a context manager temporarily override __getitem__ for an instance? I'm thinking:

with col.index_mode('copy_on_getitem'):
    col_new = col[i0:i1]

where __getitem__ is your current getitem?

Ah, that does seem like a nice idea for convenience. It should actually be pretty simple to override, e.g.

In [1]: class A:
   ...:     def __getitem__(self, item):
   ...:         return item
   ...:         

In [2]: a = A()

In [5]: class context:
    def __init__(self, a):
        self.a = a
    def __enter__(self):
        self.func_copy = self.a.__getitem__
        self.a.__getitem__ = lambda x: x*2
    def __exit__(self, exc_type, exc_value, traceback):
        self.a.__getitem__ = self.func_copy
   ...:         

In [7]: a[5]
5

In [8]: with context(a):
   ...:     print(a[5])
   ...:     
10

In [9]: a[5]
5

@mdmueller - it looks like there is a doctest that needs skipping on Windows (see the AppVeyor 2.6 failure)

@mdmueller - instead of skipping the doctest you can add the type (and check that all your examples specify int64 where needed).

t = Table([(1, 2, 3, 4), (10, 1, 9, 9)], names=('a', 'b'), dtype=[np.int64, np.int64])

To try finishing this out and to provide a passing base for #4090, I've cloned this PR off to #4202 and added a commit to fix the Windows docstring problem. If that passes then I'll merge #4202.

Closed by #4202.