On 5 Dec 2006, at 15:51, Fredrik Lundh wrote: > Alastair Houghton wrote: > >> What's more, I think it will be confusing for Python newbies because >> they'll see someone doing >> >> m[3] >> >> and assume that m is a list-like object, then complain when things >> like >> >> for match in m: >> print match > > that'll work, of course, which might be confusing for people who think > they understand how for-in works but don't ;)
Or (as in my case) guessed at how it works because they can't be bothered to check the code and can't remember from the last time they looked. I don't spend a great deal of time in the guts of Python. But I do use it and have a couple of extensions that I've written for it (one of which I was contemplating releasing publicly and that is impacted by this change---it provides, amongst other things, an alternate implementation of the "re" API, so I'm going to want to implement this too). >> or >> >> m[3:4] >> >> fail to do what they expect. > > the problem with slicing is that people may 1) expect a slice to > return > a new object *of the same type* What I would have expected is that it supported a similar set of sequence methods---that is, that it returned something with a similar signature. I don't see why code would care about it being the exact same type. Anyway, clearly what people will expect here (talking about the match object API) is that m[3:4] would give them a list (or some equivalent sequence object) containing groups 3 and 4. Why do you think someone would expect a match object? > 2) expect things like [::-1] to work, which opens up another can of > worms. As long as they aren't expecting it to return the same type of object, is there a can of worms here? > I prefer the "If the implementation is easy to explain, it may be a > good idea." design principle over "can of worms" design principle. 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]). Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
