[Python-ideas] Range and slice syntax

Mon Nov 12 11:23:21 EST 2018

I mostly like the abstraction being proposed, but the syntactical edge
cases like `[::3]` (infinite list crashes) and {4:10} (a dict not a
slice/range set) tip the balance against it for me.  Saying to add some
various stars and parens in various not-really-obvious places just makes
the proposal way too much special casing.

Moreover, we can get what we want without new syntax.  Or at least the bulk
of it.  Both Pandas and NumPy offer special accessors for slices that look
the way you'd like:

>>> import pandas as pd
>>> import numpy as np
>>> I = pd.IndexSlice
>>> J = np.s_
>>> I[4:10:3]
slice(4, 10, 3)
>>> J[4:10:3]
slice(4, 10, 3)

These are incredibly simple classes, but they are worth including because
many programmers will forget how to write their own.

You don't get your range-like behavior with those, but it's easy to
construct. I'm having a think-o. I think it should be possible to make a
RangeSlice class that will act like an enhanced version of pd.IndexSlice,
but my try was wrong.

But simpler:

>>> def R(sl):
...     return range(sl.start, sl.stop, sl.step or sys.maxsize)
...
>>> for i in R(I[4:10:3]):
...     print(i)
...
4
7

Someone should figure out how to make that simply `RS[4:10:3]` that will
act both ways. :-)

On Mon, Nov 12, 2018 at 10:44 AM Nicholas Harrison <
nicholasharrison222 at gmail.com> wrote:

> That's true. I should clarify what I was thinking a bit more. Maybe it's
> better to say that the new syntax creates a slice object:
>
> (::) # this creates slice(None, None, None)
>
> It accepts any object into its arguments and they default to None when
> they are left off. This can be passed into list indexing and used as a
> slice. The new addition is that slice is now iterable:
>
> iter(slice(None, None, None)) # becomes valid
>
> Only when this is called (implicitly or explicitly) do checks for valid
> objects and bounds occur. From my experience using slices, this is how they
> work in that context too.
>
> my_slice = slice('what?') # slice(None, 'what?', None)
>
> my_list[my_slice] # TypeError: slice indices must be integers or None or
> have an __index__ method
>
> # similarly
>
> iter(my_slice) # TypeError: slice indices must be integers or None or have
> an __index__ method
>
>
> I still may not understand slices well enough though.
>
> On Sun, Nov 11, 2018 at 5:13 AM Vladimir Filipović <hemflit at gmail.com>
> wrote:
>
>> On Sun, Nov 11, 2018 at 6:59 AM Nicholas Harrison
>> <nicholasharrison222 at gmail.com> wrote:
>>
>> > Any of the values may be omitted and in the slice context the behavior
>> has no changes from what it already does: start and stop default to the
>> beginning or end of the list depending on direction and the step defaults
>> to 1.
>>
>> Just to point out, with slices it's a bit more complicated than that
>> currently.
>>
>> The start, stop and step values each default to None.
>>
>> When slice-indexing built-in and (all? probably, not sure)
>> standard-library types, None values for start and stop are interpreted
>> consistently with what you described as defaults.
>> A None value for step is interpreted as either 1 or -1, depending on
>> the comparison of start and step, and accounting for None values in
>> either of them too.
>>
>> ------
>>
>> In real life I've found a use for non-integer slice objects, and been
>> happy that Python allowed me to treat the slice as a purely syntactic
>> construct whose semantics (outside builtins) are not fixed.
>>
>> My case was an interface to an external sparse time-series store, and
>> it was easy to make the objects indexable with [datetime1 : datetime2
>> : timedelta], with None's treated right etc.
>>
>> (The primary intended use was in a REPL in a data-science context, so
>> if your first thought was a doubt about whether that syntax is neat or
>> abusive, please compare it to numpy or pandas idioms, not to
>> collection classes you use in server or application code.)
>>
>> If this had not been syntactically possible, it would not have been a
>> great pain to have to work around it, but now it's existing code and I
>> can imagine other existing projects adapting the slice syntax to their
>> own needs. At first blush, it seems like your proposal would give
>> slices enough compulsory semantics to break some of such existing code
>> - maybe even numpy itself.
>>
>> (FWIW, I've also occasionally had a need for non-integer ranges, and
>> chafed at having to implement or install them. I've also missed
>> hashable slices in real life, because functools.lru_cache.)
>>
>> ------
>>
>> (Note I'm just a random person commenting on the mailing list, not
>> anybody with any authority or influence.)
>>
>> I find this recurring idea of unifying slices and ranges seductive.
>> But it would take a lot more shaking-out to make sure the range
>> semantics can be vague-ified enough that they don't break non-integer
>> slice usage.
>>
>> Also, I could imagine some disagreements about exactly how much
>> non-standard slice usage should be protected from breakage. Someone
>> could make the argument that _some_ objects as slice parameters are
>> just abuse and no sane person should have used them in the first
>> place. ("Really, slicing with [int : [[sys], ...] : __import__]? We
>> need to take care to not break THAT too?")
>> _______________________________________________
>> Python-ideas mailing list
>> Python-ideas at python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181112/7f0196f5/attachment-0001.html>