On 6 Dec 2006, at 20:29, Josiah Carlson wrote: > The problem is that either we return a list (easy), or we return > something that is basically another match object (not quite so easy). > Either way, we would be confusing one set of users or another. By not > including slicing functionality by default, we sidestep the confusion. But I don't believe that *anyone* will find it confusing that it returns a list. It's much more likely to be confusing to people that they have to write list(m)[x:y] or [m[i] for i in xrange(x,y)] when m[x] and m[y] work just fine. >> As someone who is primarily a *user* of Python, I prefer the idea >> that sequence objects should operate consistently to the idea that >> there might be some that don't. By which I mean that anything that >> supports indexing using integer values should ideally support slicing >> (including things like [::-1]). > > You are being inconsistant. You want list, tuple, etc. to be > consistant, > but you don't want match objects to be consistant. Sorry, but that is > silly. Better to not support slices than to confuse the hell out of > people by returning a tuple or list from a match slicing. That's not true *and* I object to your characterisation of the idea as "silly". What I'm saying is that the idea of slicing always returning the same exact type of object is pointless consistency, because nobody will care *provided* the thing that is returned supports a sensible set of operations given the original type. Look, I give in. There's no point trying to convince any of you further, and I don't have the time or energy to press the point. Implement it as you will. If necessary it can be an extension of my "re" replacement that slicing is supported on match objects. Kind regards, Alastair. -- http://alastairs-place.net
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