Jerome Kelleher

Yeah, an array of ``site_ids`` would probably be quite handy. Probably the ``SiteRange`` implementation is the way to go then, it's easy enough to implement.

Good idea. Why not make the ``individuals`` and ``samples`` arguments mutually exclusive though? Seems simpler, and I can't think of a good reason for mixing them.

I think ``samples`` defaults to None already (in this case it'll take all the samples in the ts). So another ``individuals=None`` argument should work fine.

Any ragged column could be cleared with affecting the referential integrity. The questions is whether we can be bothered adding methods for all of them (or if they would be...

No, there's any number of different ways it could fail I'm afraid, and without higher-level metadata APIs we're wasting our time trying to enumerate them.

@petrelharp is right in that the behaviour is intentional and reflects the definition that we're using. We can definitely explore having an option to change that, although it's not immediately...

Note that some of the changes made to the test suite for #2172 can be made simpler using this functionality.

Good idea - I guess the distinction is whether you want to returned value to be a numpy array or a string. There's definitely value in getting a numpy array...

@hyanwong - any thoughts on names here? I feel like this is quite a handy feature and we should support "encoding" the variant data in string or numpy format. We...

Great idea @hyanwong, very clever! I doubt many people are using ``Tree.parent_array``, so we could consider just nuking it. However, we do need to be careful with performance here. Counterintuitively,...