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/
