On Tue, Aug 25, 2020 at 2:26 AM Christopher Barker
As for "why not" not being a motivator -- I agree, I posted it that easy because this conversation has brought up a number of examples where slice syntax is nice to use. And David Mertz pointed out, both numpy and pandas have a utility to make easier slices -- yes, that's an argument for why you don't need them, but it's also an argument for why there IS a need for slice objects outside of the square brackets, and if we need slice objects, then slice syntax is nice.
Pandas is kinda special though. It semi-abuses Python syntax in quite a few places. For example, here is an example from the Pandas docs:
idx = pd.IndexSlice>>> dfmi.loc[idx[:, 'B0':'B1'], :]
There is a hierarchical index (MultiIndex) where we want to put slices as some of the "dimensions" of slice items. It definitely makes sense in the Pandas world, but I have never once encountered anywhere I would want "stand-alone" slice objects outside of Pandas. I know NumPy includes the same convenience, but it's not even coming to me immediately in what context you would want that in NumPy. Personally, I like the single letter `I` even more than the `idx` name in the example. But in general, having to use a somewhat special object to do something that really is rare and special doesn't feel like a big burden. Moreover, as others have noted, in dictionaries and elsewhere, allowing slices as generic expressions allows for very confusing looking code (I won't say it's *definitely* ambiguous, but certainly hard for humans to make sense of, even if the parser could). -- The dead increasingly dominate and strangle both the living and the not-yet born. Vampiric capital and undead corporate persons abuse the lives and control the thoughts of homo faber. Ideas, once born, become abortifacients against new conceptions.