On Sat, Jul 28, 2018 at 9:44 AM Jonathan Fine <jfine2358@gmail.com> wrote:
By all means start a PEP (on github) if you find it helps you. I think
it's too early.

If this problem has a pure Python solution, then I think it best to
develop it as a third party module. I suggest the name slicetools.
When slicetools is established, has users and is stable. That would be
the time to submit the PEP. I think it would give a smoother and
easier path.

For most proposals, I would agree that agree that a reference implementation as a third-party library makes sense. But operator.subscript so simple that it would be counter productive to write it in third-party module. 

The pure Python reference implementation for operator.subscript is literally four lines (or three lines, with __class_getitem__ in Python 3.7):

class _Subscript:
    def __getitem__(self, key):
        return key
subscript = _Subscript()

Very few people would use an implementation in a third-party package, because it seems unlikely to be worth the trouble of adding a dependency for so few lines of code -- copy & paste is actually more maintainable. This exact same operator also already exists in two popular third-party Python packages by the names numpy.s_ and pandas.IndexSlice. 

That said, the actual logic is not obvious, unless you already understand the details of how Python's indexing works. So most user code does not benefit in clarity by copying and pasting it.