@eteq - in no particular order:

>  do you just mean you implemented this directly in ccdproc? Do you want some code review of that at some point?

Yes and yes; @crawfordsm and are making progress on ccdproc and will be talking on skype tomorrow. I'd guess we are 1-2 weeks from being ready for a review, with the understanding that some of what has been implemented will need to change.

I tend towards getting a functional draft out, knowing it will need revision, over trying to get all potential revisions worked before having something that works (hopefully that made sense).

> specifically address the zero-vs-one index problem

*shudder*...it has been a few years since I've worked in a language that wasn't zero-indexed.

Points well taken, though -- it would be nice (though probably impossible) to have some way of catching these index errors, and documentation needs to emphasize this issue.

> We really don't want to encourage the use of older idioms when one already exists in python....So here's an intermediate solution: accept both. That is, have the docstrings encourage the use of slice objects

Oddly, I see ``"[:, 100:110]"`` as more pythonic than ``(slice(None), slice(100, 110))`` but there may be a better way of doing rectangular slices than that...I think that was one of the other things that led me down the string route.  ``slice`` can only do one dimension, so the check would need to be for a tuple (or list?) of slice objects, each of which is a bit of a wordy to generate.
 
Another alternative is to go with the implementation @crawfordsm originally had for this:
```python
def subtract_overscan(ccd, oscan)
```
where both ``ccd`` and ``oscan`` are ``CCDData`` objects, so the call becomes
``ccddata = subtract_overscan(ccddata, ccddata[:, 100:100])``. This has the virtue of being clear and compact!

It is maybe worth re-emphasizing that something is getting implemented so that there will be a concrete implementation to react to, with the expectation that the implementation will be re-worked, potentially substantially.