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!