Ben Wing wrote: > the only strangeness here is the numbering of groups starting at 1, and > making 0 be a special case. this isn't any more (or less) of a problem > for the indexing form than it is for m.group(), and it's well known from > various other languages. we could always consider making groups start > at 0 for python 3000, but this seems to me like a gratuitous > incompatibility with the rest of the world. As Greg pointed out, this is just a special case of the fact that subgroups can be nested with the ordering governed by the location of the left parenthesis: .>>> import re .>>> m = re.match("a(b(c))", "abc") .>>> m.group(0) 'abc' .>>> m.group(1) 'bc' .>>> m.group(2) 'c' That said, I like the definitions in your last message: len(m) == 1 + len(m.groups()) m[:] == [m.group(0)] + m.groups() all(m[i] == m.group(i) for i in range(len(m))) all(m[k] == m.group(k) for k in m.groupdict().keys()) The internally inconsistent* m.group() and m.groups() methods could even be slated for removal in Py3k (replaced by the subscript operations). Cheers, Nick. *The inconsistency being that group() considers the whole match to be group 0, while groups() does not. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
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