[Python-Dev] PEP 203 Augmented Assignment

[Thomas Wouters]

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!