[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:
[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!