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