Re: [Python-ideas] slice[] to get more complex slices

[Stephan Hoyer]

On Sat, Jul 28, 2018 at 9:44 AM Jonathan Fine  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.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Jonathan Fine]

Hi Stephan

I took a look at your personal web site. Your PhD sounds interesting.
Quantum coherence and photosynthesis. But off-topic here. (Sadly,
personal web sites are a bit of mess.)

You wrote:
> I'd really like to move this proposal forward in some form.

+10

> As a next step, would it be helpful to summarize the use cases and reasoning
> in a PEP?

0

Here's my two cents worth of opinion.

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 example, PEP 428 proposes the inclusion of a third-party module,
pathlib, in the standard library.
https://mail.python.org/pipermail/python-ideas/2018-July/052255.html
https://www.python.org/dev/peps/pep-0428/

For more on my general approach to building a third-party library, see my posts.
https://mail.python.org/pipermail/python-ideas/2018-July/052464.html
https://mail.python.org/pipermail/python-ideas/2018-July/052470.html

That's the end of my two cents.

Oh, and those who have time and energy to contribute. They get the biggest vote.

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

Re: [Python-ideas] slice[] to get more complex slices

[Stephan Hoyer]

On Mon, Jul 23, 2018 at 4:37 PM David Mertz  wrote:

> I find pandas.IndexSlice makes a lot of operations easier to spell. As
> simple as it is, it's a valuable capability. Rather than every library—or a
> number of them anyway—creating the same 4 lines of code with a different
> name, it would be much nicer to have it as a class __getitem__ method, e.g.
> slice[...], or as an attribute of the slice object, such as
> slice.literal[...].
>

I'd really like to move this proposal forward in some form.

There have been three basic proposals for where to put the __getitem__
based constructor:
1. slice: slice[...] potentially conflicts with typing syntax.
2. slice.literal: This is potentially confusing, because in many cases it
does not actually create a single slice object.
3. operator.subscript: This is the last proposal standing, and was also the
outcome of the previous discussion on python-ideas:
https://mail.python.org/pipermail/python-ideas/2015-June/034086.html

I think the repeated interest in this topic demonstrates that there are
real use cases for operator.subscript, even though it would be slightly
less accessible than putting it directly on slice or slice.literal.

As a next step, would it be helpful to summarize the use cases and
reasoning in a PEP?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Stephan Hoyer]

On Mon, Jul 23, 2018 at 4:19 PM Stefan Behnel  wrote:

> Stephan Hoyer schrieb am 23.07.2018 um 18:01:
> > I think a SliceHelper class like this is a reasonable solution, but there
> > would be a lot of value having it a standard place somewhere in the
> > standard library (e.g., operator.subscript).
> >
> > Both pandas and NumPy include this helper object under different names
> > (pandas.IndexSlice and numpy.index_exp / numpy.s_), but it would be
> > surprising/unexpected for pandas/numpy specific helpers to show up when
> not
> > using one of those libraries. I do the exact same sorts of indexing
> > manipulations with xarray, dask and TensorFlow.
> >
> > Given that this is basically a simple feature to make it easier to work
> > with Python syntax (so there's no danger it will change in the future), I
> > think there is a lot to be said for putting it in the standard library in
> > one place so it's obvious what to use and users don't have to relearn
> that
> > name for this object and/or reimplement it.
>
> Please copy that comment into the ticket and ask for it to be reopened.
>
> https://bugs.python.org/issue24379
>
> Stefan
>

I basically did exactly that last week! See
https://bugs.python.org/issue24379#msg321966

I was told, "You may get more traction on python-ideas" :)

Cheers,
Stephan
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[David Mertz]

I find pandas.IndexSlice makes a lot of operations easier to spell. As
simple as it is, it's a valuable capability. Rather than every library—or a
number of them anyway—creating the same 4 lines of code with a different
name, it would be much nicer to have it as a class __getitem__ method, e.g.
slice[...], or as an attribute of the slice object, such as
slice.literal[...].

On Mon, Jul 23, 2018, 7:20 PM Stefan Behnel  wrote:

> Stephan Hoyer schrieb am 23.07.2018 um 18:01:
> > On Mon, Jul 23, 2018 at 4:24 AM Paul Moore wrote:
> >
> >> I thought the reason the proposal got nowhere was because it's pretty
> >> simple to define it yourself:
> >>
> >> >>> class SliceHelper:
> >> ... def __getitem__(self, slice):
> >> ... return slice
> >> ...
> >> >>> SH = SliceHelper()
> >> >>> SH[1::3]
> >> slice(1, None, 3)
> >>
> >> Did I miss something significant about why this wasn't sufficient?
> >
> >
> > I think a SliceHelper class like this is a reasonable solution, but there
> > would be a lot of value having it a standard place somewhere in the
> > standard library (e.g., operator.subscript).
> >
> > Both pandas and NumPy include this helper object under different names
> > (pandas.IndexSlice and numpy.index_exp / numpy.s_), but it would be
> > surprising/unexpected for pandas/numpy specific helpers to show up when
> not
> > using one of those libraries. I do the exact same sorts of indexing
> > manipulations with xarray, dask and TensorFlow.
> >
> > Given that this is basically a simple feature to make it easier to work
> > with Python syntax (so there's no danger it will change in the future), I
> > think there is a lot to be said for putting it in the standard library in
> > one place so it's obvious what to use and users don't have to relearn
> that
> > name for this object and/or reimplement it.
>
> Please copy that comment into the ticket and ask for it to be reopened.
>
> https://bugs.python.org/issue24379
>
> Stefan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Stefan Behnel]

Stephan Hoyer schrieb am 23.07.2018 um 18:01:
> On Mon, Jul 23, 2018 at 4:24 AM Paul Moore wrote:
> 
>> I thought the reason the proposal got nowhere was because it's pretty
>> simple to define it yourself:
>>
>> >>> class SliceHelper:
>> ... def __getitem__(self, slice):
>> ... return slice
>> ...
>> >>> SH = SliceHelper()
>> >>> SH[1::3]
>> slice(1, None, 3)
>>
>> Did I miss something significant about why this wasn't sufficient?
> 
> 
> I think a SliceHelper class like this is a reasonable solution, but there
> would be a lot of value having it a standard place somewhere in the
> standard library (e.g., operator.subscript).
> 
> Both pandas and NumPy include this helper object under different names
> (pandas.IndexSlice and numpy.index_exp / numpy.s_), but it would be
> surprising/unexpected for pandas/numpy specific helpers to show up when not
> using one of those libraries. I do the exact same sorts of indexing
> manipulations with xarray, dask and TensorFlow.
> 
> Given that this is basically a simple feature to make it easier to work
> with Python syntax (so there's no danger it will change in the future), I
> think there is a lot to be said for putting it in the standard library in
> one place so it's obvious what to use and users don't have to relearn that
> name for this object and/or reimplement it.

Please copy that comment into the ticket and ask for it to be reopened.

https://bugs.python.org/issue24379

Stefan

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

Re: [Python-ideas] slice[] to get more complex slices

[George Leslie-Waksman]

May I propose `slice.L` as in "slice literal":

```
class slice:
...
class L:
"""Slice literal.

slice.L[1:2:3, 1] -> (slice(1, 2, 3), slice(1))
"""

@classmethod
def __class_getitem__(cls, item):
return item
```

On Mon, Jul 23, 2018 at 12:02 PM Joseph Jevnik  wrote:

> I still think that 'operator.subscript' would be valuable to me for
> all of the same reasons discussed in the previous threads and issues.
> I don't understand why it was reverted without any serious discussion
> given that it was already accepted and many people find this useful.
>
> On Mon, Jul 23, 2018 at 2:38 PM, Serhiy Storchaka 
> wrote:
> > 23.07.18 18:16, Guido van Rossum пише:
> >>
> >> On Mon, Jul 23, 2018 at 3:24 AM, Jeroen Demeyer  >> > wrote:
> >>
> >> On 2018-07-23 11:58, Grégory Lielens wrote:
> >>
> >> Not sure slice[1::3] can be done
> >>
> >>
> >> It can be done. Since "slice" is a class, it would require a
> >> metaclass though.
> >>
> >>
> >> Since PEP 560 it won't need a metaclass -- it can be implemented as
> >> __class_getitem__.
> >
> >
> > Do you bless using __class_getitem__ for something other than typing?
> >
> >
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Joseph Jevnik]

I still think that 'operator.subscript' would be valuable to me for
all of the same reasons discussed in the previous threads and issues.
I don't understand why it was reverted without any serious discussion
given that it was already accepted and many people find this useful.

On Mon, Jul 23, 2018 at 2:38 PM, Serhiy Storchaka  wrote:
> 23.07.18 18:16, Guido van Rossum пише:
>>
>> On Mon, Jul 23, 2018 at 3:24 AM, Jeroen Demeyer > > wrote:
>>
>> On 2018-07-23 11:58, Grégory Lielens wrote:
>>
>> Not sure slice[1::3] can be done
>>
>>
>> It can be done. Since "slice" is a class, it would require a
>> metaclass though.
>>
>>
>> Since PEP 560 it won't need a metaclass -- it can be implemented as
>> __class_getitem__.
>
>
> Do you bless using __class_getitem__ for something other than typing?
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Jonathan Fine]

Humour warning.

Serhiy wrote:

> Do you bless using __class_getitem__ for something other than typing?

As in https://perldoc.perl.org/functions/bless.html, perhaps?

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

Re: [Python-ideas] slice[] to get more complex slices

[Serhiy Storchaka]

23.07.18 18:16, Guido van Rossum пише:
On Mon, Jul 23, 2018 at 3:24 AM, Jeroen Demeyer 
> wrote:


On 2018-07-23 11:58, Grégory Lielens wrote:

Not sure slice[1::3] can be done


It can be done. Since "slice" is a class, it would require a
metaclass though.


Since PEP 560 it won't need a metaclass -- it can be implemented as 
__class_getitem__.


Do you bless using __class_getitem__ for something other than typing?

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

Re: [Python-ideas] slice[] to get more complex slices

[Stephan Hoyer]

On Mon, Jul 23, 2018 at 4:24 AM Paul Moore  wrote:

> I thought the reason the proposal got nowhere was because it's pretty
> simple to define it yourself:
>
> >>> class SliceHelper:
> ... def __getitem__(self, slice):
> ... return slice
> ...
> >>> SH = SliceHelper()
> >>> SH[1::3]
> slice(1, None, 3)
>
> Did I miss something significant about why this wasn't sufficient?


I think a SliceHelper class like this is a reasonable solution, but there
would be a lot of value having it a standard place somewhere in the
standard library (e.g., operator.subscript).

Both pandas and NumPy include this helper object under different names
(pandas.IndexSlice and numpy.index_exp / numpy.s_), but it would be
surprising/unexpected for pandas/numpy specific helpers to show up when not
using one of those libraries. I do the exact same sorts of indexing
manipulations with xarray, dask and TensorFlow.

Given that this is basically a simple feature to make it easier to work
with Python syntax (so there's no danger it will change in the future), I
think there is a lot to be said for putting it in the standard library in
one place so it's obvious what to use and users don't have to relearn that
name for this object and/or reimplement it.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Guido van Rossum]

On Mon, Jul 23, 2018 at 3:24 AM, Jeroen Demeyer  wrote:

> On 2018-07-23 11:58, Grégory Lielens wrote:
>
>> Not sure slice[1::3] can be done
>>
>
> It can be done. Since "slice" is a class, it would require a metaclass
> though.
>

Since PEP 560 it won't need a metaclass -- it can be implemented as
__class_getitem__.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Paul Moore]

On 23 July 2018 at 13:19, Todd  wrote:
> On Mon, Jul 23, 2018 at 7:24 AM, Paul Moore  wrote:
>>
>> On 23 July 2018 at 11:31, Jeroen Demeyer  wrote:
>> > On 2018-07-23 12:24, Jeroen Demeyer wrote:
>> >>
>> >> Another solution that nobody has mentioned (as far as I know) is to add
>> >> additional syntax to the language for that. For example, one could say
>> >> that (1:3) could be used to construct slice(1, 3) directly. The
>> >> parentheses are required to avoid confusion with type hints. I'm not a
>> >> Python language expert, but I don't think that type hints can occur
>> >> inside parentheses like that.
>> >
>> >
>> > And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of
>> > slices too.
>>
>> I thought the reason the proposal got nowhere was because it's pretty
>> simple to define it yourself:
>>
>> >>> class SliceHelper:
>> ... def __getitem__(self, slice):
>> ... return slice
>> ...
>> >>> SH = SliceHelper()
>> >>> SH[1::3]
>> slice(1, None, 3)
>>
>> Did I miss something significant about why this wasn't sufficient?
>>
>> Paul
>
>
> That involves initializing an instance, which doesn't serve any purpose in
> this case and I was hoping to avoid.

Well it serves the purpose that you can do it already in current
Python, rather than needing a core interpreter change and limiting
your code to Python 3.8+ only ;-)

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

Re: [Python-ideas] slice[] to get more complex slices

[Todd]

On Mon, Jul 23, 2018 at 7:24 AM, Paul Moore  wrote:

> On 23 July 2018 at 11:31, Jeroen Demeyer  wrote:
> > On 2018-07-23 12:24, Jeroen Demeyer wrote:
> >>
> >> Another solution that nobody has mentioned (as far as I know) is to add
> >> additional syntax to the language for that. For example, one could say
> >> that (1:3) could be used to construct slice(1, 3) directly. The
> >> parentheses are required to avoid confusion with type hints. I'm not a
> >> Python language expert, but I don't think that type hints can occur
> >> inside parentheses like that.
> >
> >
> > And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of
> > slices too.
>
> I thought the reason the proposal got nowhere was because it's pretty
> simple to define it yourself:
>
> >>> class SliceHelper:
> ... def __getitem__(self, slice):
> ... return slice
> ...
> >>> SH = SliceHelper()
> >>> SH[1::3]
> slice(1, None, 3)
>
> Did I miss something significant about why this wasn't sufficient?
>
> Paul


That involves initializing an instance, which doesn't serve any purpose in
this case and I was hoping to avoid.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Todd]

On Mon, Jul 23, 2018 at 6:28 AM, Jonathan Fine  wrote:

> Hi Grégory
>
> You wrote:
> > Oh yes , I see. Seems like almost everybody think using the [...] syntax
> to
> > define reusable slices is a good idea,
>
> > Not sure slice[1::3] can be done, but this has my preference too: it's
> the
> > most direct exposure I can think of...
>
> The slice class already has all the core functionality it needs. This
> thread is looking for something extra. My preference is to create a
> new module, slicetools, that contains the functionality the people on
> this thread want to have.
>
> What I like about this approach is that the code can be written and
> deployed without getting permission from anyone. And when it's done
> and has a body of practice, the PEP would simply be "Add slicetools to
> the standard library".
>
> Anyone here up for working on that sort of approach?
>
>
I only proposed on very limited thing here.  My thought was that if it
wasn't accepted in the slice class the next best place would be a dedicated
class in boltons or toolz or some package like that.

Besides the __getitem__ --> slice classmethod, what other functionality do
you think is needed in such a module?
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Todd]

On Mon, Jul 23, 2018 at 6:24 AM, Jeroen Demeyer  wrote:

> On 2018-07-23 11:58, Grégory Lielens wrote:
>
>> Not sure slice[1::3] can be done
>>
>
> It can be done. Since "slice" is a class, it would require a metaclass
> though.
>
> Another solution that nobody has mentioned (as far as I know) is to add
> additional syntax to the language for that. For example, one could say that
> (1:3) could be used to construct slice(1, 3) directly. The parentheses are
> required to avoid confusion with type hints. I'm not a Python language
> expert, but I don't think that type hints can occur inside parentheses like
> that.
>
>
If I remember correctly Guido explicitly rejected requests for such
syntax.  This proposal was intended as a compromise.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Grégory Lielens]

That would be even more directbut it require syntax support, usefull 
mainly for people doing multdim complex slicing (i.e numpy users). I may be 
wrong, but I do not see it gain much support outside numpy...

slice[] is probably much more easy to swallow for standard python 
users, and almost as good imho.
It reuse getitem, so it imply the produced slice will behaves exactly like 
it would if it was not stored/reused, and almost garantee it will be the 
case indeed (even if the slice syntax is extended)

Getting this to work including a new module would be nice. Eventually, 
having it standard is positive too, it means slice manipulation will become 
more standardised.

On Monday, July 23, 2018 at 12:32:04 PM UTC+2, Jeroen Demeyer wrote:
>
> On 2018-07-23 12:24, Jeroen Demeyer wrote: 
> > Another solution that nobody has mentioned (as far as I know) is to add 
> > additional syntax to the language for that. For example, one could say 
> > that (1:3) could be used to construct slice(1, 3) directly. The 
> > parentheses are required to avoid confusion with type hints. I'm not a 
> > Python language expert, but I don't think that type hints can occur 
> > inside parentheses like that. 
>
> And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of 
> slices too. 
> ___ 
> Python-ideas mailing list 
> python...@python.org  
> https://mail.python.org/mailman/listinfo/python-ideas 
> Code of Conduct: http://python.org/psf/codeofconduct/ 
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Paul Moore]

On 23 July 2018 at 11:31, Jeroen Demeyer  wrote:
> On 2018-07-23 12:24, Jeroen Demeyer wrote:
>>
>> Another solution that nobody has mentioned (as far as I know) is to add
>> additional syntax to the language for that. For example, one could say
>> that (1:3) could be used to construct slice(1, 3) directly. The
>> parentheses are required to avoid confusion with type hints. I'm not a
>> Python language expert, but I don't think that type hints can occur
>> inside parentheses like that.
>
>
> And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of
> slices too.

I thought the reason the proposal got nowhere was because it's pretty
simple to define it yourself:

>>> class SliceHelper:
... def __getitem__(self, slice):
... return slice
...
>>> SH = SliceHelper()
>>> SH[1::3]
slice(1, None, 3)

Did I miss something significant about why this wasn't sufficient?

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

Re: [Python-ideas] slice[] to get more complex slices

[Jeroen Demeyer]

On 2018-07-23 12:24, Jeroen Demeyer wrote:

Another solution that nobody has mentioned (as far as I know) is to add
additional syntax to the language for that. For example, one could say
that (1:3) could be used to construct slice(1, 3) directly. The
parentheses are required to avoid confusion with type hints. I'm not a
Python language expert, but I don't think that type hints can occur
inside parentheses like that.


And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of 
slices too.

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

Re: [Python-ideas] slice[] to get more complex slices

[Jonathan Fine]

Hi Grégory

You wrote:
> Oh yes , I see. Seems like almost everybody think using the [...] syntax to
> define reusable slices is a good idea,

> Not sure slice[1::3] can be done, but this has my preference too: it's the
> most direct exposure I can think of...

The slice class already has all the core functionality it needs. This
thread is looking for something extra. My preference is to create a
new module, slicetools, that contains the functionality the people on
this thread want to have.

What I like about this approach is that the code can be written and
deployed without getting permission from anyone. And when it's done
and has a body of practice, the PEP would simply be "Add slicetools to
the standard library".

Anyone here up for working on that sort of approach?

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

Re: [Python-ideas] slice[] to get more complex slices

[Jeroen Demeyer]

On 2018-07-23 11:58, Grégory Lielens wrote:

Not sure slice[1::3] can be done


It can be done. Since "slice" is a class, it would require a metaclass 
though.


Another solution that nobody has mentioned (as far as I know) is to add 
additional syntax to the language for that. For example, one could say 
that (1:3) could be used to construct slice(1, 3) directly. The 
parentheses are required to avoid confusion with type hints. I'm not a 
Python language expert, but I don't think that type hints can occur 
inside parentheses like that.



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

Re: [Python-ideas] slice[] to get more complex slices

[Grégory Lielens]

Oh yes , I see. Seems like almost everybody think using the [...] syntax to 
define reusable slices is a good idea, the discussion is where this could 
be implemented, knowing that numpy.s_ already exists.

Discussion is not easy to follow, with the patch almost accepted then 
delayed then rejected, in a very short amount of time.

In particular, it's not clear why direct indexing of slice type (not 
instance) was not chosen. It was the first proposal, and here again Todd's 
choice. it was silently skipped/changed to slice.literal then moved to 
operators, at least that's the impression I got reading  
https://bugs.python.org/issue24379 ...
Not sure slice[1::3] can be done, but this has my preference too: it's the 
most direct exposure I can think of...


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

Re: [Python-ideas] slice[] to get more complex slices

[Jonathan Fine]

Hi Grégory

You wrote:
> Seems that the initial proposal was skipped just for timing reasons

The discussion is in https://bugs.python.org/issue24379. It was first
skipped for that reason. Second time around our Then and now Former
BDFL wrote
===
https://bugs.python.org/msg280721
Actually I'm with Raymond -- I'm also not sure or mildly against (-0).
Given how easy it is to do without and how cumbersome using the operator
module is I don't see a great benefit. (IMO the operator module should be
the measure of *last* resort -- it is not to become part of anybody's
toolkit for common operators. But I seem to be a minority opinion here.)
===
and also
===
https://bugs.python.org/msg319695
Let's close it. Just because someone spent a lot of effort on a patch
we don't have to accept it.
===

That said, I see merits in providing standard tools for creating
slices. These tools, as discussed, to take advantage of the power of
the [...] syntax. I'd start here:
https://bugs.python.org/msg244801

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

Re: [Python-ideas] slice[] to get more complex slices

[Grégory Lielens]

+1 on this. Seems easy a limited in scope, and it reduce the need to 
remember the details of slice constructor, just reuse the same syntax for 
getitem slices.

Seems that the initial proposal was skipped just for timing reasons, and 
have a large support among numpy users. More mixed outside numpy, but still 
I think it was put under the rug a little too quickly...
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] slice[] to get more complex slices

[Serhiy Storchaka]

22.07.18 22:03, Todd пише:
For basic slices, the normal "slice(start, stop, step)" syntax works 
well.  But it becomes much more verbose to create more complicated 
slices that you want to re-use for multiple multidimensional data 
structures, like numpy, pandas, xarray, etc.


One idea I had was to allow creating slices by using indexing on the 
slice class.  So for example:


     x = slice[5:1:-1, 10:20:2, 5:end]

Would be equivalent to:

     x = (slice(5, 1, -1), slice(10, 20, 2), slice(5, None))

Note that this wouldn't be done on a slice instance, it would be done on 
the slice class.  The basic idea is that it would simply return whatever 
is given to __getitem__.


See https://bugs.python.org/issue24379 .

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

Re: [Python-ideas] slice[] to get more complex slices

[Stefan Behnel]

Todd schrieb am 22.07.2018 um 21:03:
> For basic slices, the normal "slice(start, stop, step)" syntax works well.
> But it becomes much more verbose to create more complicated slices that you
> want to re-use for multiple multidimensional data structures, like numpy,
> pandas, xarray, etc.
> 
> One idea I had was to allow creating slices by using indexing on the slice
> class.  So for example:
> 
> x = slice[5:1:-1, 10:20:2, 5:end]
> 
> Would be equivalent to:
> 
> x = (slice(5, 1, -1), slice(10, 20, 2), slice(5, None))
> 
> Note that this wouldn't be done on a slice instance, it would be done on
> the slice class.  The basic idea is that it would simply return whatever is
> given to __getitem__.

Personally, I always likes that idea, but it would be worth looking up the
previous discussions in the list archive to find out if they lead to any
conclusion. AFAICT, "slice.literal" was the latest such proposal that was
discussed.

Stefan

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