[Python-Dev] PEP 203 Augmented Assignment

[Thomas Wouters]

On Thu, Jul 27, 2000 at 09:22:48AM -0500, Guido van Rossum wrote:

[about INPLACE_ADD/SUBTRACT/ETC]

> There's no need for them to be consecutive!  (The BINARY_* family
> isn't even consecutive!)  I say, just some open ranges, like 54-59 and
> 73-79.

[and about ROT_ANY]

> No, let's not overgeneralize.

Roger dodger, wilco dilco, milli vanilli.

> > Try to call __getslice__ with unconverted start, stop and step
> > If it fails with a TypeError, and step is not None, raise the above error
> > Else, convert start and stop to ints like the current normal slice
> > behaviour, and try __getslice__ the old way.
> 
> No, trying to call something and retrying if it fails is a bad idea:
> the code might fail for a very different reason, and retrying it might
> mask the bug, or execute a side effect twice...

Yeah, I realized that too, while listening one of my colleagues trying to
make some point or other. Hrm... So backwards compatibility is out ? I'm not
sure howmany Python code uses slice-objects, but I would consider it a
(personal ;) failure if slicing has to be *broken* before it can be fixed.

If we can't figure out whether a function supports the 'new syntax'
reliably, I don't see how we can transform the error message either. I'll
bet inspecting the __getitem__ method to find out whether it supports the
one or the other is way too much of a runtime penalty to suffer at each
index.

So the only workable way to support all combinations of __getitem__ and
__getslice__ is by adding a new builtin, __getitems__ ? (too confusing a
name... __getanything__ ? :P)

Feeble-(after-all-those-meetings)-ly y'rs,
-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!