On 12/6/06, Josiah Carlson <[EMAIL PROTECTED]> wrote: > *We* may not be confused, but it's not about us (I'm personally happy to > use the .group() interface); it's about relative newbies who, generally > speaking, desire/need consistency (see [1] for a paper showing that > certain kinds of inconsistancies are bad - at least in terms of grading > - for new computer science students). Being inconsistant because it's > *easy*, is what I consider silly. We've got the brains, we've got the > time, if we want slicing, lets produce a match object. If we don't want > slicing, or if prodicing a slice would produce a semantically > questionable state, then lets not do it.
The idea that slicing a match object should produce a match object sounds like a foolish consistency to me. It's a useful invariant of lists that slicing them returns lists. It's not a useful invariant of sequences in general. This is similar to how it's a useful invariant that indexing a string returns a string; indexing a list generally does not return a list. I only found a couple __getslice__ definitions in a quick perusal of stdlib. ElementTree.py's _ElementInterface class returns a slice from a contained list; whereas sre_parse.py's SubPattern returns another SubPattern. UserList and UserString also define __getslice__ but I don't consider them representative of the standards of non-string/list classes. As an aside, if you're trying to show that inconsistencies in a language are bad by referencing a paper showing that people who used consistent (if incorrect) mental models scored better than those who did not, you may have to explain further; I don't see the connection. -- Michael Urman http://www.tortall.net/mu/blog _______________________________________________ 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
