> > 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/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4