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.
Huh? I thought I proposed a b/w compat solution: IF there is a __getslice__ method: IF the slice step is None: call __getslice__(lo, hi) ELSE: # the slice step is not None call __getslice__(lo, hi, step) What's wrong with that?
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.
No, we don't deal with __getitem__; if *it* doesn't support a tuple containing slice objects, tough luck. --Guido van Rossum (home page: http://www.pythonlabs.com/~guido/)