On Thu, Oct 06, 2016 at 04:19:17PM -0700, Neil Girdhar wrote:

Currently str(slice(10)) returns "slice(None, 10, None)"

If the start and step are None, consider not emitting them. Similarly slice(None) is rendered slice(None, None, None).

When you're printing a lot of slices, it's a lot of extra noise.

I have an alternative suggestion. Wouldn't it be nice if slice objects looked something like the usual slice syntax? If you think the answer is No, then you'll hate my suggestion :-) Let's keep the current repr() of slice objects as they are, using the full function-call syntax complete with all three arguments show explicitly: repr(slice(None, None, None)) => "slice(None, None, None)" But let's make str() of a slice more suggestive of actual slicing, and as a bonus, make slices easier to create too. str(slice(None, None, None)) => "slice[:]" Let the slice type itself be sliceable, as an alternate constuctor: slice[:] => returns slice(None) slice[start:] => returns slice(start, None) slice[:end] => returns slice(None, end) slice[start::step] => returns slice(start, None, step) and so forth. (This probably would require changing the type of slice to a new metaclass.) And then have str() return the compact slice syntax. At worst, the compact slice syntax is one character longer than the optimal function syntax: # proposed slice str() slice[:7] # 9 characters # proposed compact str() slice(7) # 8 characters # current str() slice(None, 7, None) # 20 characters but it will be more compact more often: slice[1:] # 9 characters versus: slice(1, None) # 14 characters slice(None, 1, None) # 20 characters -- Steve

+100 I like this idea of giving `slice` a metaclass that defines a `.__getitem__()` allowing us to construct slices on the slice type itself. FWIW, this is exactly what pandas.IndexSlice does. E.g., from http://pandas.pydata.org/pandas-docs/stable/advanced.html: In [51]: dfmi.loc[(slice('A1','A3'),slice(None), ['C1','C3']),:] In [52]: idx = pd.IndexSlice In [53]: dfmi.loc[idx[:,:,['C1','C3']],idx[:,'foo']] This is one of those nifty things that's buried in Pandas but not well documented. I'd rather spell the above simply as: dfmi.loc[slice[:,:,['C1','C3']], slice[:,'foo']] I like the change proposed to `str(slice(10))` also... and it would be way better if `slice[:10]` were actual "syntax." In fact, in that case it could even be the repr(). Note: Notwithstanding my scare quotes, Steven isn't actually asking for new syntax. "slice" is already a name, and names can already be followed by square brackets. He's just asking for a new method on a metaclass. On Sat, Nov 12, 2016 at 1:26 AM, Steven D'Aprano wrote:

On Thu, Oct 06, 2016 at 04:19:17PM -0700, Neil Girdhar wrote:

...

Currently str(slice(10)) returns "slice(None, 10, None)"

If the start and step are None, consider not emitting them. Similarly slice(None) is rendered slice(None, None, None).

When you're printing a lot of slices, it's a lot of extra noise.

I have an alternative suggestion. Wouldn't it be nice if slice objects looked something like the usual slice syntax?

If you think the answer is No, then you'll hate my suggestion :-)

Let's keep the current repr() of slice objects as they are, using the full function-call syntax complete with all three arguments show explicitly:

repr(slice(None, None, None)) => "slice(None, None, None)"

But let's make str() of a slice more suggestive of actual slicing, and as a bonus, make slices easier to create too.

str(slice(None, None, None)) => "slice[:]"

Let the slice type itself be sliceable, as an alternate constuctor:

slice[:] => returns slice(None) slice[start:] => returns slice(start, None) slice[:end] => returns slice(None, end) slice[start::step] => returns slice(start, None, step)

and so forth. (This probably would require changing the type of slice to a new metaclass.)

And then have str() return the compact slice syntax.

At worst, the compact slice syntax is one character longer than the optimal function syntax:

# proposed slice str() slice[:7] # 9 characters

# proposed compact str() slice(7) # 8 characters

# current str() slice(None, 7, None) # 20 characters

but it will be more compact more often:

slice[1:] # 9 characters

versus:

slice(1, None) # 14 characters slice(None, 1, None) # 20 characters

-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

I thought of the use of `.__getitem__()` in metaclasses in the typing module. I feel like this use is more natural and more useful than that. Should we someday need a slice generic type for PEP 484, the spelling would naturally be `Slice[T]` instead, in my mind. But `slice[1:10,2]` should be a constructor for a concrete slice object. On Sat, Nov 12, 2016 at 11:20 AM, אלעזר wrote:

On Sat, Nov 12, 2016 at 9:10 PM David Mertz wrote:

...

dfmi.loc[slice[:,:,['C1','C3']], slice[:,'foo']]

I like the change proposed to `str(slice(10))` also... and it would be way better if `slice[:10]` were actual "syntax." In fact, in that case it could even be the repr().

Indexing operator for classes already has a meaning, for generic types. It is a possibility that slice will become a generic type (see here: https://github.com/python/mypy/issues/2410#issuecomment-258898836) and this syntax will make it either impossible or require Slice[] to be different from slice[] in a potentially confusing way.

Elazar

-- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.

On Sat, Nov 12, 2016 at 11:41 AM, Ivan Levkivskyi wrote:

On 12 November 2016 at 20:27, David Mertz wrote:

...

I thought of the use of `.__getitem__()` in metaclasses in the typing module. I feel like this use is more natural and more useful than that. Should we someday need a slice generic type for PEP 484, the spelling would naturally be `Slice[T]` instead, in my mind. But `slice[1:10,2]` should be a constructor for a concrete slice object.

Slice[T] vs slice[::-1] is coherent with what we have now for List[T] vs list, etc.

Not really. We have List[T] but list[x] is invalid -- it doesn't have a different meaning (it's list instances that support indexing). And in fact the distinction between List and list is intentionally minimal -- List is simply what list wants to become when it grows up. :-) Honestly I think the use case of wanting to create a slice object is rare enough that we can continue to write slice(x, y, z). If you really find yourself wanting something shorter, I believe in the past it's been pointed out that you could create a helper, e.g. like this: class S: def __getitem__(self, x): return x s = S() a = s[:():] -- --Guido van Rossum (python.org/~guido)

The very common use case for creating slice objects is in Pandas and similar libraries. Xarray certainly, or Blaze, to a lesser extent NumPy. That said, it's very easy to define a suitable __getitem__, as Guido shows. It's really a question simply of whether that object should be named 'slice' or something else. On Nov 12, 2016 5:08 PM, "Guido van Rossum" wrote:

On Sat, Nov 12, 2016 at 11:41 AM, Ivan Levkivskyi wrote:

...

On 12 November 2016 at 20:27, David Mertz wrote:

...

I thought of the use of `.__getitem__()` in metaclasses in the typing module. I feel like this use is more natural and more useful than that. Should we someday need a slice generic type for PEP 484, the spelling would naturally be `Slice[T]` instead, in my mind. But `slice[1:10,2]` should be a constructor for a concrete slice object.

Slice[T] vs slice[::-1] is coherent with what we have now for List[T] vs list, etc.

Not really. We have List[T] but list[x] is invalid -- it doesn't have a different meaning (it's list instances that support indexing). And in fact the distinction between List and list is intentionally minimal -- List is simply what list wants to become when it grows up. :-)

Honestly I think the use case of wanting to create a slice object is rare enough that we can continue to write slice(x, y, z). If you really find yourself wanting something shorter, I believe in the past it's been pointed out that you could create a helper, e.g. like this:

class S: def __getitem__(self, x): return x s = S()

a = s[:():]

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

On Nov 12, 2016 5:46 PM, "David Mertz" 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:

...

In [1]: class Slice: ...: def __init__(self): ...: self.slice = slice ...: def __getitem__(self, x): ...: return x ...: def __call__(self, *args, **kws): ...: return self.slice(*args, **kws) ...:

In [2]: slice = Slice()

In [3]: slice(1,10,2) Out[3]: slice(1, 10, 2)

In [4]: slice[1:10:2] Out[4]: slice(1, 10, 2)

I'm sure there are some less common uses of the name 'slice' that would

break here. That's why I'd want an official standard behavior. isinstance(obj, slice) would be a notable one. -n

But let's make str() of a slice more suggestive of actual slicing, and as a bonus, make slices easier to create too.

str(slice(None, None, None)) => "slice[:]"

following all the later discussion, I'd like to come back to this initial part of this thread: An even briefer for for just "str" would be to omit the 'slice' part str(slice(None, None, None)) => "[:]" etc. Since it has colons in there, it's clear it is a slice. And it is very brief notation. -Alexander

On 13 November 2016 at 04:07, Guido van Rossum wrote:

On Sat, Nov 12, 2016 at 5:46 PM, David Mertz 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

On Sat, Nov 12, 2016 at 7:35 PM, Alexander Heger wrote:

But let's make str() of a slice more suggestive of actual slicing, and

...

as a bonus, make slices easier to create too.

str(slice(None, None, None)) => "slice[:]"

following all the later discussion, I'd like to come back to this initial part of this thread: An even briefer for for just "str" would be to omit the 'slice' part

str(slice(None, None, None)) => "[:]"

etc. Since it has colons in there, it's clear it is a slice. And it is very brief notation.

It is also confusing -- it is surrounded by [] but it is not a list (not even close). -- --Guido van Rossum (python.org/~guido)