On Thu, Jul 27, 2000 at 12:30:51PM -0500, Guido van Rossum wrote:
Actually, it wasn't the feebleness as much as the two different things you seem to be wanting, Guido ;) Previously (in another thread, and perhaps in the start of this thread as well) you argued that an index should always call __getitem__, with a slice object if it's a slice of some kind, *even a basic one*. So that we lose __getslice__ and rather teach people to use __getslice__.
That would be nice, but it would be b/w incompatible, so now we're trying (again) to figure out how to still support __getslice__. My proposal is to try and be b/w compatible if __getslice__ exists. See my previous mail.
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 ? 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. 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__. Then again, the use of this method is quite different from __getattr__/__setattr__... Most classes will commit to either a sequence-type or a mapping-type, and not even bother with extended slices or tuple-indexes. 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. 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. (and make builtin objects accept sliceobjects too !) Perhaps try to slowly deprecate getslice__. Give plenty __of examples of using __getitem__ and slice objects in the standard documentation. 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. I suspect this is all for 2.1 or later, though. (As for what ?!ng suggested, the variable-args __hooks__, I don't see a difference between __getitem__(self, *val) and __getitem__(self, val) where val is a tuple. The same reasoning stands.)
So now you want to *extend* the 'special case' to extended, 3-argument slices, but *not* Ellipses and tupled-slices (which aren't really tuples, because you can do (1, 2:5, ...)) -- or am I reading this wrong ? :)
Not sure what you mean by that. (1, 2:5, ...) by itself is illegal syntax; the special slice syntax can only occur directly in an indexing context, e.g. a[1, 2:5, ...].
Exactly my point ;P Ferget it, not important. What I was trying to say was that: x[1, 2, 4:10:2] isn't the same as x[(1, 2, 4:10:2)] So the first isn't really indexing with a tuple -- because you can't do the 2nd. But the result as passed to __getitem__ *is* a tuple, so forget what I said ;)
Don't worry, Guido, it isn't just you, I failed to grasp what those managers were trying to tell me today, too... I may just be too dense, today.
I hope they weren't telling you to stop working on Python! You seem made for this work...
Heh, nono, they don't have any say over what I do with Python. I'd force them to join the Python Consortium before I'd let them have any say over that ;) I don't do any *work* with Python, other than waiting for Barry to bring Mailman 2.0 out of beta so we can start a 'product line' on that, instead of Majordomo. It has nothing to do with Python but everything with my colleagues ;-) In fact, the only people who even know what Python is are my direct colleagues, my co-System-administrators, one of which is my direct boss. I didn't even see those people today, because half the meetings today and yesterday were with a bunch of product developers and the senior VP of technology (that's his translated title), and the other half was with the workers council, the management team and the CEO (sort of) of the company. And besides, even if they did try to tell me to stop with Python, it would go like the first episode of Red Dwarf, where Lister comes out of stasis and Holly, the shipboard computer, tries to tell him everyone's dead and he's been in stasis for 3 million years. "So where is everyone, Hol ?" "They're dead, Dave." "Who, the captain ?" "Everyone, Dave." "What, Petersen ?" "Yes, Dave. Everyone. Everyone is dead." "Not Kochansky!" "Yes, Dave. Everyone is dead. Dead is everyone. Is everyone dead. Dead everyone is." "Wait. What are you trying to tell me here, Hol ?" "You have to quit with Python, even in your free time." "What are you trying to tell me ?" ... And if that failed, I'd quit. I don't work here to get dictated how to do my work, and I certainly don't work here to get dictated how to live my life *outside* of work. I realize that's how PythonLabs operates<big wink> but it's not how we run things in the old country, Guido ! :) No, all work I did and am doing on and with Python was hobby work. Which is just fine with me, for the moment, because it means I can slow down the pace whenever I want to. (Not that I've had that urge yet.) Can't-imagine-working-full-time-on-or-with-Python---two-week-bliss!- -seven-week-burnout-ly y'rs, -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!