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@gmail.com> wrote:
On Sun, Nov 11, 2018 at 6:59 AM Nicholas Harrison <nicholasharrison222@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@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/