@hunse, from an API design perspective, it's typically good to raise the exceptions early and explicitly. This means using custom subclasses of exceptions, or raising known exceptions ourselves rather than letting them implicitly fall through other functions. I am being hypocritical in that currently I let the `IndexError` fall through the numpy slicing in `_pad_transform`, but I will be fixing this soon. Although it adds more code, the benefits are two-fold: the possible exceptions become self-documenting at the API level (making it easy to maintain a list of exceptions in the actual documentation, and for developers to understand the surface area), and the message can be made more informative. And I do agree that this sort of stuff is good to document for the user. Currently it's very easy to trip over all the invariants that we expect between arguments.