On Thu, Jul 27, 2000 at 12:03:39PM -0500, Guido van Rossum wrote: > > 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? Well, what happens if __getslice__ and __getitem__ both exist, and __getitem__ is used to handle extended slices, but __getslice__ isn't (yet)? Currently, if it's a single item, __getitem__ is called. If it's a basic slice, __getslice__ is called. If it's an extended slice, __getitem__ is called. In the above picture, __getslice__ would be called instead, with the 'wrong' number of arguments, and the use of extended slices would break. > > 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. Sorry, that was my feebleness popping up. I was talking about __getslice__. How do we find out if __getslice__ accepts 4 arguments, rather than 3 ? -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
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