rework Series.sort is_view check on underlying ndarray before inplace sort (GH5856)

[jreback]

closes #5856
related #5853

DataFrame._ixs will properly record a cache change (similar to _get_item_cache)

[jreback]

This was a cache issue (and not related to is_copy)

df.iloc[:,0] takes a different path as df[0] and caches differently in how it gets the result

(as the former uses iget its data and the latter get)

[jreback]

@y-p @jseabold ok by you?

[ghost]

I don't understand what the "cache" has to do with the fact the the series values are a view
on a larger ndarray. What exactly is being cached?

in so far as @jseabold can now do if s._is_cached, yeah looks fine.

[jreback]

this series was created as a slice from a frame

when selecting a column of a frame the frame caches a reference to the created series

the series holds a weak reference back to the parent

if the series is modified it is reflected in the frame (and in the cached series) which may not be the same object but represent the same data

the reason for this is that when u get a series from a frame it MAY be a view (and usually but not always is)

this system if refs and a back weak ref allow for view propagation even when numpy doesn't provide a view

[ghost]

Thanks, that's a good overview.

What you describe sounds like reference bookkeeping to me, I still don't understand why it's
termed a cache, but that's not a big deal.

What does "view propagation" mean?

[jreback]

yep like ref counting

view propagation means a change in the series will reflect in the DataFrame thru the numpy view mechanism

but their are times when the series is changed that requires it to be done in a non-trivial way that numpy cannot propogate thru a view (eg a dtype change in the series)

this cache ref then allows the series to be updated in the parent data frame

effectively it allows one to break a view yet still have it work