> Yes. So what we're talking about is a better way to do indexing all
> together, all types in one shot. ('indexes', 'slices' and 'collections' ?
> I'm not sure how to name the first and the last one, if not that.) And not
> just indexing, but setting and deleting at the same time, right ?
Yes.
> So the most preferred way is to pass a single argument which is either:
>
> - A single object (directly what was passed in) for a single index.
> - A slice-object if any kind of single-slice was passed in, which holds the
> zero-to-three objects that the slice was 'created' with.
> - A tuple of zero or more of either of the above two.
(Make that a tuple of two or more!) Indexing like a[] is illegal, and
indexing like a[i] passes a non-tuple.
> While I'm writing this down, I'm not sure if it's such a good idea. Isn't
> this placing a tad too much into one function ? It might require some severe
> logic to support this all, especially if you give 'special' meanings to some
> indexes. And we're inserting a new catch-all method -- a set of them,
> actually: get, set and del -- and that while Paul is trying to solve the
> other catch-all Python has, __getattr__/__setattr__.
Actually, __getitem__ *already* has to deal with -- the only case it
doesn't get currently is the step-less single slice, which gets passed
to __getslice__ -- and dies if it's not there.
> And lets not forget the convenience of writing those methods: __getitem__ is
> intuitive, both in name and semantics. So is __getslice__. The passing of a
> slice object to __getitem__ is a tad less intuitive, and a tuple of
> index/slice objects even less.
Don't worry, that's already the case.
> I'm tempted to suggest a single change: when __getslice__ is not defined,
> pass a slice object (with no step, as if the slice had a trailing ':') to
> __getitem__, and document it properly.
Great! That's *exactly* what I've been proposing.
> (and make builtin objects accept
> sliceobjects too !)
That gets a +1 from me too, in general (there's some doubt about the
usefulness of things like ``L1[lo:ho:step] = L2'').
> Perhaps try to slowly deprecate getslice__.
Yes.
> Give plenty
> __of examples of using __getitem__ and slice objects
> in the standard documentation.
Sure.
> Also, I think it makes sense to make slice
> objects indexable, so that you can do:
>
> start, end, step = sliceobj
>
> instead of the less intuitive
>
> start, end, step = sliceobj.start, sliceobj.end, sliceobj.step
>
> But I've never used slice objects myself, so I can't really say whether it's
> a good idea.
Maybe that's a good idea.
> I suspect this is all for 2.1 or later, though.
Actually, the actual change (fall back on __*item__ with a slice
object when __*slice__ doesn't exist) should be simple to add for
2.0. Just submit to the SF PM!
--Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4