Sounds good.

On Sun, Nov 13, 2016 at 3:25 AM, Ivan Levkivskyi <levkivskyi@gmail.com> wrote:
On 13 November 2016 at 04:07, Guido van Rossum <guido@python.org> wrote:

On Sat, Nov 12, 2016 at 5:46 PM, David Mertz <mertz@gnosis.cx> wrote:
If we *do* want the name 'slice' as the spelling for the thing that can either be called or indexed to create a slice object, we could probably use some boilerplate like this:

I can't stop you from doing that in your own session, but I don't want to reuse the builtin slice object for that. If this is so useful with Pandas maybe the Pandas library can define its own helper for this purpose.

This reminds me @ vs .dot() for matrix multiplication a bit. Pandas has IndexSlicer, NumPy has index_exp, etc. I think it would be nice to have a simple common way to express this.
But here we have an additional ingredient -- generic types. I think that a reasonable compromise would be to simply continue the way proposed in http://bugs.python.org/issue24379 -- just add operator.subscript for this purpose. Pros:
* subscript is not a class, so that subscript[...] will be not confused with generics;
* this does not require patching built-ins;
* all libraries that need this will get a "common interface" in stdlib, operator module seems to be good place for this.

The patch for operator.subscript was already applied, but it is now reverted because it caused a refleak.
I have submitted a new patch that does not cause refleaks, I just replaced empty __slots__ with a __setattr__:
it looks like __slots__ are not needed here to save memory (there is only a singleton instance),
they were used just to create an immutable object.

--
Ivan





--
--Guido van Rossum (python.org/~guido)