[Python-Dev] PEP 203 Augmented Assignment

Thomas Wouters thomas@xs4all.net
Thu, 27 Jul 2000 17:48:03 +0200

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


> 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

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!